Requirements Register
Product and cybersecurity architecture understanding package generated from Markdown-derived requirements.
Executive Summary
Search and Filters
Requirements Table
This table is horizontally scrollable. Use the bottom scrollbar to view all columns.
| ID | Requirement / Expectation | Security Feature | Traceability | Status | Details |
|---|---|---|---|---|---|
| REQ-AUTO-00001 | The cybersecurity concept shall describe the scope of the risk analysis, risks that were identified during the risk analysis, cybe rsecurity goals, cybersecurity requirements, mitigation strategies, validation, and verification strategies, etc.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA; Cybersecurity requirement handling | Interface: OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: The cybersecurity concept shall describe the scope of the risk analysis, risks that were identified during the risk analysis, cybe rsecurity goals, cybersecurity requirements, mitigation strategies, validation, and verification strategies, etc. Engineering expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA; Cybersecurity requirement handling. Interface view: OEM/Customer Review Interface. Architecture view: Security Services; OEM/Customer Review Interface. Mapped security capability: Cybersecurity requirement handling Mapped feature: Cybersecurity requirement handling; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: Security Services; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 3 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_SEC_0001 | Cybersecurity methods and strategiesThe supplier shall provide documentation describing their strategies and methods for working with embedded systems cybersecurity.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Cybersecurity Evidence and DIA; Supplier Development and Production Hardening; Cybersecurity requirement handling | Interface: OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: Cybersecurity methods and strategies REQ_SEC_0001 The supplier shall provide documentation describing their strategies and methods for working with embedded systems cybersecurity. Engineering expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Engineering interpretation: Security view: Cybersecurity Evidence and DIA; Supplier Development and Production Hardening; Cybersecurity requirement handling. Interface view: OEM/Customer Review Interface. Architecture view: Security Services; OEM/Customer Review Interface. Mapped security capability: Cybersecurity requirement handling Mapped feature: Cybersecurity requirement handling; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: Security Services; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 5 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_SEC_0002 | Risk assessmentThe supplier shall perform risk assessment based on a threat and vulnerability analysis for each release, including any vehicle manufacturer-specific adaptations.Expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Vulnerability and Incident Handling; Supplier Development and Production Hardening; Vulnerability management | Interface: OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: Risk assessment REQ_SEC_0002 The supplier shall perform risk assessment based on a threat and vulnerability analysis for each release, including any vehicle manufacturer-specific adaptations. Engineering expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Engineering interpretation: Security view: Vulnerability and Incident Handling; Supplier Development and Production Hardening; Vulnerability management. Interface view: OEM/Customer Review Interface. Architecture view: Security Services; OEM/Customer Review Interface. Mapped security capability: Vulnerability management Mapped feature: Vulnerability management Mapped interface: OEM/Customer Review Interface Mapped architecture element: Security Services; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 5 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00004 | Method and scope shall be proposed to and approved by the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Missing security feature | Medium Not needed | DetailsFull requirement statement: Method and scope shall be proposed to and approved by the vehicle manufacturer. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 5 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00005 | Documentation on the method and results shall be provided to the vehicle manufacturer.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Cybersecurity Evidence and DIA | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: Documentation on the method and results shall be provided to the vehicle manufacturer. Engineering expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Engineering interpretation: Security view: Cybersecurity Evidence and DIA. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 5 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00006 | Note: The vehicle manufacturer and supplier shall collaboratively define the context of the system or function to enable the supplier performing the risk assessment.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface Status: Complete | Medium Needed | DetailsFull requirement statement: Note: The vehicle manufacturer and supplier shall collaboratively define the context of the system or function to enable the supplier performing the risk assessment. Engineering expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Engineering interpretation: Security view: Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: Application Software; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: Application Software; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 5 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ_SEC_0003 | Cybersecurity conceptThe supplier shall describe the cybersecurity concept and how it is implemented in hardware and software respectively.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Cybersecurity Evidence and DIA; Supplier Development and Production Hardening; Cybersecurity requirement handling | Interface: OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: Cybersecurity concept REQ_SEC_0003 The supplier shall describe the cybersecurity concept and how it is implemented in hardware and software respectively. Engineering expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Engineering interpretation: Security view: Cybersecurity Evidence and DIA; Supplier Development and Production Hardening; Cybersecurity requirement handling. Interface view: OEM/Customer Review Interface. Architecture view: Security Services; OEM/Customer Review Interface. Mapped security capability: Cybersecurity requirement handling Mapped feature: Cybersecurity requirement handling Mapped interface: OEM/Customer Review Interface Mapped architecture element: Security Services; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 5 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_SEC_0022 | Marcus Lindner EPXC Published 6(16)All risks identified in cybersecurity risk analyses shall be evaluated.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Cybersecurity requirement handling | Interface: None Architecture: Security Services Status: Missing interface | High Not needed | DetailsFull requirement statement: Marcus Lindner EPXC Published 6(16) REQ_SEC_0022 All risks identified in cybersecurity risk analyses shall be evaluated. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Cybersecurity requirement handling. Architecture view: Security Services. Mapped security capability: Cybersecurity requirement handling Mapped feature: Cybersecurity requirement handling Mapped interface: None Mapped architecture element: Security Services Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 6 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00009 | For each risk identified in the cybersecurity risk analyses, a risk treatment decision shall be made to avoid, reduce, share, or retain the risk.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Vulnerability and Incident Handling; Cybersecurity requirement handling | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: For each risk identified in the cybersecurity risk analyses, a risk treatment decision shall be made to avoid, reduce, share, or retain the risk. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Vulnerability and Incident Handling; Cybersecurity requirement handling. Architecture view: Security Services. Mapped security capability: Cybersecurity requirement handling Mapped feature: Cybersecurity requirement handling Mapped interface: None Mapped architecture element: Security Services Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 6 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_SEC_0023 | Cybersecurity controls shall sufficiently reduce the risk.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Cybersecurity requirement handling | Interface: None Architecture: Security Services Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_SEC_0023 Cybersecurity controls shall sufficiently reduce the risk. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Cybersecurity requirement handling. Architecture view: Security Services. Mapped security capability: Cybersecurity requirement handling Mapped feature: Cybersecurity requirement handling Mapped interface: None Mapped architecture element: Security Services Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 6 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00011 | It shall be possible to verify which cybersecurity controls were derived from which requirements.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification; Cybersecurity requirement handling | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: It shall be possible to verify which cybersecurity controls were derived from which requirements. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Cybersecurity requirement handling. Architecture view: Security Services. Mapped security capability: Cybersecurity requirement handling Mapped feature: Cybersecurity requirement handling Mapped interface: None Mapped architecture element: Security Services Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 6 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_SEC_0024 | The cybersecurity concept of the supplier shall contain a documentation of the accepted residual risk and be agreed with the vehicle manufacturer.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Cybersecurity Evidence and DIA; Supplier Development and Production Hardening; Cybersecurity requirement handling | Interface: OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: REQ_SEC_0024 The cybersecurity concept of the supplier shall contain a documentation of the accepted residual risk and be agreed with the vehicle manufacturer. Engineering expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Engineering interpretation: Security view: Cybersecurity Evidence and DIA; Supplier Development and Production Hardening; Cybersecurity requirement handling. Interface view: OEM/Customer Review Interface. Architecture view: Security Services; OEM/Customer Review Interface. Mapped security capability: Cybersecurity requirement handling Mapped feature: Cybersecurity requirement handling; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: Security Services; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 6 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_SEC_0004 | Verification and validationThe supplier shall provide documentation of the verification and validation methods of cybersecurity features.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA; Supplier Development and Production Hardening; Cybersecurity requirement handling | Interface: OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: Verification and validation REQ_SEC_0004 The supplier shall provide documentation of the verification and validation methods of cybersecurity features. Engineering expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA; Supplier Development and Production Hardening; Cybersecurity requirement handling. Interface view: OEM/Customer Review Interface. Architecture view: Security Services; OEM/Customer Review Interface. Mapped security capability: Cybersecurity requirement handling Mapped feature: Cybersecurity requirement handling; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: Security Services; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 6 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_SEC_0005 | The supplier shall provide test reports detailing the results from the verification and validation of cybersecurity features.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA; Supplier Development and Production Hardening; Cybersecurity requirement handling | Interface: OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: REQ_SEC_0005 The supplier shall provide test reports detailing the results from the verification and validation of cybersecurity features. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA; Supplier Development and Production Hardening; Cybersecurity requirement handling. Interface view: OEM/Customer Review Interface. Architecture view: Security Services; OEM/Customer Review Interface. Mapped security capability: Cybersecurity requirement handling Mapped feature: Cybersecurity requirement handling; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: Security Services; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 6 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_SEC_0040 | The vehicle manufacturer reserves the right to perform penetration testing on the ECU to identify potential vulnerabilities.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | None | Interface: None Architecture: None Status: Missing security feature, interface, architecture | Medium Needed | DetailsFull requirement statement: REQ_SEC_0040 The vehicle manufacturer reserves the right to perform penetration testing on the ECU to identify potential vulnerabilities. Engineering expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Engineering interpretation: Traceability needs review before this requirement can be used as design evidence. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 6 Classification: Reclassified as Informational Mandatory level: Informational Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ_SEC_0007 | DocumentationAn inventory of software and protocols, including their versions, shall be provided by the supplier.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Cybersecurity Evidence and DIA; Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: Documentation REQ_SEC_0007 An inventory of software and protocols, including their versions, shall be provided by the supplier. Engineering expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Engineering interpretation: Security view: Cybersecurity Evidence and DIA; Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: Application Software; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Application software behavior; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: Application Software; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 6 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_SEC_0025 | Marcus Lindner EPXC Published 7(16)A BOM containing part numbers and versions of hardware components used in the product shall be provided by the supplier.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: Hardware Platform; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: Marcus Lindner EPXC Published 7(16) REQ_SEC_0025 A BOM containing part numbers and versions of hardware components used in the product shall be provided by the supplier. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: Hardware Platform; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: OEM/Customer Review Interface Mapped architecture element: Hardware Platform; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 7 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_SEC_0041 | The vehicle manufacturer reserves the right to request documentation and evidence as well as to perform or order a compliance audit to determine whether the listed requirements are fulfilled.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Security Logging and Event Handling; Cybersecurity Evidence and DIA | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: REQ_SEC_0041 The vehicle manufacturer reserves the right to request documentation and evidence as well as to perform or order a compliance audit to determine whether the listed requirements are fulfilled. Engineering expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Engineering interpretation: Security view: Security Logging and Event Handling; Cybersecurity Evidence and DIA. Mapped security capability: None Mapped feature: Security evidence and traceability Mapped interface: None Mapped architecture element: None Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 7 Classification: Reclassified as Informational Mandatory level: Informational Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ_SEC_0042 | The vehicle manufacturer and the supplier shall set up a cybersecurity DIA to agree on the responsibilities for the distributed cybersecurity activities.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Cybersecurity Evidence and DIA; Supplier Development and Production Hardening; Cybersecurity requirement handling | Interface: OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: REQ_SEC_0042 The vehicle manufacturer and the supplier shall set up a cybersecurity DIA to agree on the responsibilities for the distributed cybersecurity activities. Engineering expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Engineering interpretation: Security view: Cybersecurity Evidence and DIA; Supplier Development and Production Hardening; Cybersecurity requirement handling. Interface view: OEM/Customer Review Interface. Architecture view: Security Services; OEM/Customer Review Interface. Mapped security capability: Cybersecurity requirement handling Mapped feature: Cybersecurity requirement handling Mapped interface: OEM/Customer Review Interface Mapped architecture element: Security Services; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 7 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_SEC_0008 | Software securityThe ECU shall be able to verify integrity and authenticity of a vehicle manufacturer-specified set of data stored within the ECU.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification; Authentication | Interface: OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: Software security REQ_SEC_0008 The ECU shall be able to verify integrity and authenticity of a vehicle manufacturer-specified set of data stored within the ECU. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Authentication. Interface view: OEM/Customer Review Interface. Architecture view: Security Services; OEM/Customer Review Interface. Mapped security capability: Authentication Mapped feature: Authentication Mapped interface: OEM/Customer Review Interface Mapped architecture element: Security Services; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 7 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00021 | Methods shall be proposed to and approved by the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Missing security feature | Medium Not needed | DetailsFull requirement statement: Methods shall be proposed to and approved by the vehicle manufacturer. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 7 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_SEC_0009 | Security architectureThe supplier shall apply methods for isolation of software/hardware components and data to reduce the effect in case of a cybersecurity breach.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening; Cybersecurity requirement handling | Interface: OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: Security architecture REQ_SEC_0009 The supplier shall apply methods for isolation of software/hardware components and data to reduce the effect in case of a cybersecurity breach. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening; Cybersecurity requirement handling. Interface view: OEM/Customer Review Interface. Architecture view: Security Services; OEM/Customer Review Interface. Mapped security capability: Cybersecurity requirement handling Mapped feature: Cybersecurity requirement handling Mapped interface: OEM/Customer Review Interface Mapped architecture element: Security Services; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 7 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_SEC_0020 | Cryptographic librariesSelection of cryptographic methods and their use shall be agreed upon between the vehicle manufacturer and the supplier.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: Cryptographic libraries REQ_SEC_0020 Selection of cryptographic methods and their use shall be agreed upon between the vehicle manufacturer and the supplier. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 7 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_SEC_0010 | ServicesAll network services implemented in the ECU shall undergo hardening.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control; Supplier Development and Production Hardening | Interface: None Architecture: Hardware Platform Status: Missing interface | High Not needed | DetailsFull requirement statement: Services REQ_SEC_0010 All network services implemented in the ECU shall undergo hardening. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control; Supplier Development and Production Hardening. Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 8 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_SEC_0011 | The ECU shall only expose network and communication services that have been agreed upon with the vehicle manufacturer.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: OEM/Customer Review Interface Architecture: Hardware Platform; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: REQ_SEC_0011 The ECU shall only expose network and communication services that have been agreed upon with the vehicle manufacturer. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Interface view: OEM/Customer Review Interface. Architecture view: Hardware Platform; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: OEM/Customer Review Interface Mapped architecture element: Hardware Platform; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 8 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_SEC_0012 | InterfacesCommunication interfaces shall use boundary controls such as ingress/egress filtering.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: Interfaces REQ_SEC_0012 Communication interfaces shall use boundary controls such as ingress/egress filtering. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 8 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_SEC_0013 | Communication boundary controls shall be configurable by the vehicle manufacturer.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: REQ_SEC_0013 Communication boundary controls shall be configurable by the vehicle manufacturer. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 8 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00028 | Methods shall be proposed and approved by the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Missing security feature | Medium Not needed | DetailsFull requirement statement: Methods shall be proposed and approved by the vehicle manufacturer. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 8 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_SEC_0014 | Any interfaces used for development purposes shall be removed or disabled in series production.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control; Supplier Development and Production Hardening | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_SEC_0014 Any interfaces used for development purposes shall be removed or disabled in series production. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control; Supplier Development and Production Hardening. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 8 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00030 | The details shall be agreed upon between the vehicle manufacturer and the supplier.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: The details shall be agreed upon between the vehicle manufacturer and the supplier. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 8 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_SEC_0026 | Only hardware interfaces and protocols specified by the vehicle manufacturer shall be available in series production.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control; Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: Hardware Platform; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: REQ_SEC_0026 Only hardware interfaces and protocols specified by the vehicle manufacturer shall be available in series production. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control; Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: Hardware Platform; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: OEM/Customer Review Interface Mapped architecture element: Hardware Platform; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 8 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_SEC_0027 | Information securityIt shall be possible for the vehicle manufacturer to securely inject data into the product in accordance with the specification provided by the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Cybersecurity requirement handling | Interface: OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: Information security REQ_SEC_0027 It shall be possible for the vehicle manufacturer to securely inject data into the product in accordance with the specification provided by the vehicle manufacturer. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Cybersecurity requirement handling. Interface view: OEM/Customer Review Interface. Architecture view: Security Services; OEM/Customer Review Interface. Mapped security capability: Cybersecurity requirement handling Mapped feature: Cybersecurity requirement handling Mapped interface: OEM/Customer Review Interface Mapped architecture element: Security Services; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 8 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_SEC_0028 | Marcus Lindner EPXC Published 9(16)Data specified by the vehicle manufacturer shall be protected from manipulations.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Missing security feature | High Not needed | DetailsFull requirement statement: Marcus Lindner EPXC Published 9(16) REQ_SEC_0028 Data specified by the vehicle manufacturer shall be protected from manipulations. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_SEC_0029 | Data specified by the vehicle manufacturer shall be protected from disclosure.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Missing security feature | High Not needed | DetailsFull requirement statement: REQ_SEC_0029 Data specified by the vehicle manufacturer shall be protected from disclosure. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_SEC_0006 | Intellectual property of the vehicle manufacturer shall be protected from disclosure.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Missing security feature | High Not needed | DetailsFull requirement statement: REQ_SEC_0006 Intellectual property of the vehicle manufacturer shall be protected from disclosure. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_SEC_0016 | Key managementIt shall be possible for the vehicle manufacturer to securely inject key material and other data used for cybersecurity controls into the ECU according to the specification of the vehicle manufacturer.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Key and Certificate Handling; Key management | Interface: OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: Key management REQ_SEC_0016 It shall be possible for the vehicle manufacturer to securely inject key material and other data used for cybersecurity controls into the ECU according to the specification of the vehicle manufacturer. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Key and Certificate Handling; Key management. Interface view: OEM/Customer Review Interface. Architecture view: Security Services; OEM/Customer Review Interface. Mapped security capability: Key management Mapped feature: Key management Mapped interface: OEM/Customer Review Interface Mapped architecture element: Security Services; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_SEC_0019 | Secrets, public keys and other data used for cybersecurity controls in production vehicle systems shall be different from those used in pre-production phases.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Key and Certificate Handling; Supplier Development and Production Hardening; Key management | Interface: None Architecture: Security Services Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_SEC_0019 Secrets, public keys and other data used for cybersecurity controls in production vehicle systems shall be different from those used in pre-production phases. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Key and Certificate Handling; Supplier Development and Production Hardening; Key management. Architecture view: Security Services. Mapped security capability: Key management Mapped feature: Key management Mapped interface: None Mapped architecture element: Security Services Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_SEC_0021 | ECUs shall only contain the secrets agreed between the vehicle manufacturer and the supplier.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Key and Certificate Handling; Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: REQ_SEC_0021 ECUs shall only contain the secrets agreed between the vehicle manufacturer and the supplier. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Key and Certificate Handling; Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_SEC_0015 | ECUs shall conform to the harmonized Security Access specification [1] provided by the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC; Cybersecurity requirement handling | Interface: OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: REQ_SEC_0015 ECUs shall conform to the harmonized Security Access specification [1] provided by the vehicle manufacturer. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Cybersecurity requirement handling. Interface view: OEM/Customer Review Interface. Architecture view: Security Services; OEM/Customer Review Interface. Mapped security capability: Cybersecurity requirement handling Mapped feature: Cybersecurity requirement handling Mapped interface: OEM/Customer Review Interface Mapped architecture element: Security Services; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_SEC_0043 | Security updatesIt shall be possible to update the software of the ECU.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Secure Software Update; Cybersecurity requirement handling | Interface: None Architecture: Security Services Status: Missing interface | High Not needed | DetailsFull requirement statement: Security updates REQ_SEC_0043 It shall be possible to update the software of the ECU. Engineering expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Engineering interpretation: Security view: Secure Software Update; Cybersecurity requirement handling. Architecture view: Security Services. Mapped security capability: Cybersecurity requirement handling Mapped feature: Cybersecurity requirement handling Mapped interface: None Mapped architecture element: Security Services Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_SEC_0030 | Marcus Lindner EPXC Published 10(16)The supplier shall inform the vehicle manufacturer if any cybersecurity patches are available.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Vulnerability and Incident Handling; Supplier Development and Production Hardening; Cybersecurity requirement handling | Interface: OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: Marcus Lindner EPXC Published 10(16) REQ_SEC_0030 The supplier shall inform the vehicle manufacturer if any cybersecurity patches are available. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Vulnerability and Incident Handling; Supplier Development and Production Hardening; Cybersecurity requirement handling. Interface view: OEM/Customer Review Interface. Architecture view: Security Services; OEM/Customer Review Interface. Mapped security capability: Cybersecurity requirement handling Mapped feature: Cybersecurity requirement handling Mapped interface: OEM/Customer Review Interface Mapped architecture element: Security Services; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_SEC_0044 | Incident managementAn incident response process shall be proposed to and approved by the vehicle manufacturer.Expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Vulnerability and Incident Handling | Interface: OEM/Customer Review Interface Architecture: Compliance Process; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: Incident management REQ_SEC_0044 An incident response process shall be proposed to and approved by the vehicle manufacturer. Engineering expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Engineering interpretation: Security view: Vulnerability and Incident Handling. Interface view: OEM/Customer Review Interface. Architecture view: Compliance Process; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: Compliance Process; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_SEC_0045 | In case of cybersecurity incidents, the incident response process shall be used.Expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Vulnerability and Incident Handling; Incident response | Interface: None Architecture: Security Services Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_SEC_0045 In case of cybersecurity incidents, the incident response process shall be used. Engineering expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Engineering interpretation: Security view: Vulnerability and Incident Handling; Incident response. Architecture view: Security Services. Mapped security capability: Incident response Mapped feature: Incident response Mapped interface: None Mapped architecture element: Security Services Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_SEC_0046 | The incident response process shall be maintained for the entire product lifetime.Expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Vulnerability and Incident Handling | Interface: None Architecture: Compliance Process Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_SEC_0046 The incident response process shall be maintained for the entire product lifetime. Engineering expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Engineering interpretation: Security view: Vulnerability and Incident Handling. Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_SEC_0032 | The incident response process shall ensure that risk is managed in coordination with the vehicle manufacturer.Expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Vulnerability and Incident Handling | Interface: OEM/Customer Review Interface Architecture: Compliance Process; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: REQ_SEC_0032 The incident response process shall ensure that risk is managed in coordination with the vehicle manufacturer. Engineering expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Engineering interpretation: Security view: Vulnerability and Incident Handling. Interface view: OEM/Customer Review Interface. Architecture view: Compliance Process; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: Compliance Process; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_SEC_0033 | Vulnerability managementAny vulnerabilities that are identified during product lifecycle shall be promptly communicated to the vehicle manufacturer.Expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Vulnerability and Incident Handling | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: Vulnerability management REQ_SEC_0033 Any vulnerabilities that are identified during product lifecycle shall be promptly communicated to the vehicle manufacturer. Engineering expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Engineering interpretation: Security view: Vulnerability and Incident Handling. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00047 | The report shall include information needed to identify the affected vehicles/products.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The report shall include information needed to identify the affected vehicles/products. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00048 | Methods including the stipulation of a reasonable notification time shall be proposed to and approved by the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Missing security feature | Medium Not needed | DetailsFull requirement statement: Methods including the stipulation of a reasonable notification time shall be proposed to and approved by the vehicle manufacturer. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_SEC_0034 | Following each identified and reported vulnerability, the supplier and vehicle manufacturer shall agree on an initial response to the vulnerability.Expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Vulnerability and Incident Handling; Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: REQ_SEC_0034 Following each identified and reported vulnerability, the supplier and vehicle manufacturer shall agree on an initial response to the vulnerability. Engineering expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Engineering interpretation: Security view: Vulnerability and Incident Handling; Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_SEC_0035 | Marcus Lindner EPXC Published 11(16)Within adequate time after the initial vulnerability report, the supplier shall provide more information about the identified vulnerability.Expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Vulnerability and Incident Handling; Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: Marcus Lindner EPXC Published 11(16) REQ_SEC_0035 Within adequate time after the initial vulnerability report, the supplier shall provide more information about the identified vulnerability. Engineering expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Engineering interpretation: Security view: Vulnerability and Incident Handling; Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00051 | The information shall contain • the version(s) of affected hardware or software components, • nature of the vulnerability, • description of the affected cybersecurity goal, • technical conditions to exploit the vulnerability, • impact of the exploitation and • possibilities to remove the vulnerability.Expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Vulnerability and Incident Handling; Vulnerability management | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: The information shall contain • the version(s) of affected hardware or software components, • nature of the vulnerability, • description of the affected cybersecurity goal, • technical conditions to exploit the vulnerability, • impact of the exploitation and • possibilities to remove the vulnerability. Engineering expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Engineering interpretation: Security view: Vulnerability and Incident Handling; Vulnerability management. Architecture view: Security Services. Mapped security capability: Vulnerability management Mapped feature: Vulnerability management Mapped interface: None Mapped architecture element: Security Services Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00052 | Methods including the stipulation of a reasonable reporting time shall be proposed to and approved by the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Missing security feature | Medium Not needed | DetailsFull requirement statement: Methods including the stipulation of a reasonable reporting time shall be proposed to and approved by the vehicle manufacturer. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_SEC_0036 | The supplier shall have a method for monitoring available vulnerability databases for vulnerabilities that can affect the delivered product.Expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Secure Communication and Boundary Control; Vulnerability and Incident Handling; Supplier Development and Production Hardening | Interface: External Interfaces; OEM/Customer Review Interface Architecture: External Interfaces; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: REQ_SEC_0036 The supplier shall have a method for monitoring available vulnerability databases for vulnerabilities that can affect the delivered product. Engineering expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Engineering interpretation: Security view: Secure Communication and Boundary Control; Vulnerability and Incident Handling; Supplier Development and Production Hardening. Interface view: External Interfaces; OEM/Customer Review Interface. Architecture view: External Interfaces; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: External interfaces Mapped interface: External Interfaces; OEM/Customer Review Interface Mapped architecture element: External Interfaces; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_SEC_0037 | Identified vulnerabilities shall be considered in all current development projects or projects under field monitoring.Expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Vulnerability and Incident Handling; Supplier Development and Production Hardening | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_SEC_0037 Identified vulnerabilities shall be considered in all current development projects or projects under field monitoring. Engineering expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Engineering interpretation: Security view: Vulnerability and Incident Handling; Supplier Development and Production Hardening. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_SEC_0047 | Product lifecycleAn ECU returned from field shall allow for field-return analysis.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Hardware Platform Status: Missing security feature, interface | High Not needed | DetailsFull requirement statement: Product lifecycle REQ_SEC_0047 An ECU returned from field shall allow for field-return analysis. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_SEC_0048 | Field-return analysis secrets shall not be operational in the field.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Key and Certificate Handling | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_SEC_0048 Field-return analysis secrets shall not be operational in the field. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Key and Certificate Handling. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_SEC_0049 | An ECU enabled for field-return analysis shall not be possible to use as a spare part.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Hardware Platform Status: Missing security feature, interface | High Not needed | DetailsFull requirement statement: REQ_SEC_0049 An ECU enabled for field-return analysis shall not be possible to use as a spare part. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_SEC_0050 | Marcus Lindner EPXC Published 12(16)All secrets specified by the vehicle manufacturer shall be protected throughout the lifecycle of the ECU.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Key and Certificate Handling | Interface: OEM/Customer Review Interface Architecture: Hardware Platform; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: Marcus Lindner EPXC Published 12(16) REQ_SEC_0050 All secrets specified by the vehicle manufacturer shall be protected throughout the lifecycle of the ECU. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Key and Certificate Handling. Interface view: OEM/Customer Review Interface. Architecture view: Hardware Platform; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: OEM/Customer Review Interface Mapped architecture element: Hardware Platform; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00059 | End-of-life and decommissioning shall be specifically considered.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: End-of-life and decommissioning shall be specifically considered. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00060 | Notes: a) It shall not be possible for a third party to reuse an ECU without system support from the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: OEM/Customer Review Interface Architecture: Hardware Platform; OEM/Customer Review Interface Status: Missing security feature | Medium Not needed | DetailsFull requirement statement: Notes: a) It shall not be possible for a third party to reuse an ECU without system support from the vehicle manufacturer. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Interface view: OEM/Customer Review Interface. Architecture view: Hardware Platform; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: OEM/Customer Review Interface Mapped architecture element: Hardware Platform; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00061 | b) Decommissioning of an ECU shall not have the potential of causing unacceptable risk to the road user or the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: OEM/Customer Review Interface Architecture: Hardware Platform; OEM/Customer Review Interface Status: Missing security feature | Medium Not needed | DetailsFull requirement statement: b) Decommissioning of an ECU shall not have the potential of causing unacceptable risk to the road user or the vehicle manufacturer. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Interface view: OEM/Customer Review Interface. Architecture view: Hardware Platform; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: OEM/Customer Review Interface Mapped architecture element: Hardware Platform; OEM/Customer Review Interface Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_SEC_0051 | LoggingSecurity related events shall be identified and logged.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Security Logging and Event Handling; Logging and audit trail | Interface: None Architecture: Security Services Status: Missing interface | High Not needed | DetailsFull requirement statement: Logging REQ_SEC_0051 Security related events shall be identified and logged. Engineering expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Engineering interpretation: Security view: Security Logging and Event Handling; Logging and audit trail. Architecture view: Security Services. Mapped security capability: Logging and audit trail Mapped feature: Logging and audit trail Mapped interface: None Mapped architecture element: Security Services Source PDF: 1001379436_P10_000_01_RDDM-1140152501-1744.pdf Source Markdown: converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00063 | The gearbox itself shall be used in all drivetrains and the ECA shall be common and must be complaint to be put on any driveline setup.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The gearbox itself shall be used in all drivetrains and the ECA shall be common and must be complaint to be put on any driveline setup. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 3 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00064 | P 1 Page 2 General 2.1 The clutch actuator shall be electrically driven.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: P 1 Page 2 General 2.1 The clutch actuator shall be electrically driven. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 4 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00065 | 2.2 The actuator is placed outside of the gearbox 2.3 The ECA (Electric Clutch Actuator) must have its own internal ECU for manoeuvring and error handling.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Hardware Platform Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 2.2 The actuator is placed outside of the gearbox 2.3 The ECA (Electric Clutch Actuator) must have its own internal ECU for manoeuvring and error handling. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 4 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00066 | 2.4 The actuator will be controlled by a position and speed demand by CAN-bus 2.5 The actuator will be controlled by a position and speed demand by a 1kHz PWM signal on wake up connection 2.6 The ECA units shall be manufactured with marking variants according to the requirements in Scania STD19 (Ref 14.17).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: 2.4 The actuator will be controlled by a position and speed demand by CAN-bus 2.5 The actuator will be controlled by a position and speed demand by a 1kHz PWM signal on wake up connection 2.6 The ECA units shall be manufactured with marking variants according to the requirements in Scania STD19 (Ref 14.17). Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 4 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00067 | The variant type shall be based on delivery agreement and Brand involved.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The variant type shall be based on delivery agreement and Brand involved. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 4 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00068 | Common marking requirements that must be fulfilled for each marking variant are: Marking method: MA1 Marking height: 3 mm Date format: YYMMDD A unique serial number A DMC according to Scania STD 4562 (Ref 14.18) that contains the part number and serial number information.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Common marking requirements that must be fulfilled for each marking variant are: Marking method: MA1 Marking height: 3 mm Date format: YYMMDD A unique serial number A DMC according to Scania STD 4562 (Ref 14.18) that contains the part number and serial number information. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 4 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00069 | The marking shall not be visible when the ECA is mounted on a gearbox.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The marking shall not be visible when the ECA is mounted on a gearbox. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 4 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00070 | The ECA units shall be delivered to the required Traton brand’s production in a position in the pallet where the marking is visible.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: The ECA units shall be delivered to the required Traton brand’s production in a position in the pallet where the marking is visible. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 4 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00071 | 4.16) shall be marked according to the requirements in Scania STD19 (Ref 14.17) Tentik, wordmark variant W Part number (9 digits, two spaces in format 12 345 6789) Marking method: CAS Marking height: 2-6 mm.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 4.16) shall be marked according to the requirements in Scania STD19 (Ref 14.17) Tentik, wordmark variant W Part number (9 digits, two spaces in format 12 345 6789) Marking method: CAS Marking height: 2-6 mm. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 5 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00072 | Alternative design: CXM or equivalent combination of date dial and date field The rubber cover marking shall not be visible when the ECA is mounted on a gearbox 2.8 The ECA shall be designed with Remanufacturing and/or Refurbishment in mind with possibility of swapping out larger electronic assemblies/components.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Cybersecurity Evidence and DIA | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Alternative design: CXM or equivalent combination of date dial and date field The rubber cover marking shall not be visible when the ECA is mounted on a gearbox 2.8 The ECA shall be designed with Remanufacturing and/or Refurbishment in mind with possibility of swapping out larger electronic assemblies/components. Engineering expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Engineering interpretation: Security view: Cybersecurity Evidence and DIA. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 5 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00073 | Details to be agreed with Traton 2.9 Traton shall be invited to participate in electrical and mechanical design reviews.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Details to be agreed with Traton 2.9 Traton shall be invited to participate in electrical and mechanical design reviews. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 5 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00074 | 2.10 Traton requires extensive testing to be performed by the supplier to verify all demands stated in the requirement specification.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification; Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: 2.10 Traton requires extensive testing to be performed by the supplier to verify all demands stated in the requirement specification. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 5 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00075 | 2.11 The mechanics shall also be tested and verified, in an overall durability test as stated in Appendix B etc.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 2.11 The mechanics shall also be tested and verified, in an overall durability test as stated in Appendix B etc. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 5 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00076 | 2.12 Traton requires:Documentation of the product, i.e.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Cybersecurity Evidence and DIA | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: 2.12 Traton requires: - Documentation of the product, i.e. Engineering expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Engineering interpretation: Security view: Cybersecurity Evidence and DIA. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 5 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00077 | Should the PP be fully calculated from the AP-sensor, then this offset should not exist.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Hardware Platform Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Should the PP be fully calculated from the AP-sensor, then this offset should not exist. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 7 Classification: Not Applicable Mandatory level: Should Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00078 | P 1 Page 4 Mechanical interface 4.1 The maximum release stroke is 22,4 mm from FCCP 4.2 The total stroke of the actuator shall be 85 mm.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: P 1 Page 4 Mechanical interface 4.1 The maximum release stroke is 22,4 mm from FCCP 4.2 The total stroke of the actuator shall be 85 mm. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 8 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00079 | 4.3 The clutch actuator shall be able to reach the extreme positions A and B in with the center of the pushrod end.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 4.3 The clutch actuator shall be able to reach the extreme positions A and B in with the center of the pushrod end. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 8 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00080 | P 1 Page 4.4 ECA shall not interfere with any geometry in the 3D envelope 53612101-1 1_RFQ2030.stp except where interference fits or other types of functional contacts are required.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: P 1 Page 4.4 ECA shall not interfere with any geometry in the 3D envelope 53612101-1 1_RFQ2030.stp except where interference fits or other types of functional contacts are required. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00081 | 4.6 When the ECA is assembled, it shall not be possible to insert an object larger than Ø0,2 mm (A wire could be used as test object) between the ECA and gearbox flange, so that the object enters the space behind the ECA.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 4.6 When the ECA is assembled, it shall not be possible to insert an object larger than Ø0,2 mm (A wire could be used as test object) between the ECA and gearbox flange, so that the object enters the space behind the ECA. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00082 | 4.7 When the ECA is assembled, a gap of 3,5 mm towards surface B with a profile tolerance of ±1 mm to the nominal dimensions shall be provided.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 4.7 When the ECA is assembled, a gap of 3,5 mm towards surface B with a profile tolerance of ±1 mm to the nominal dimensions shall be provided. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00083 | The surface roughness of the ECA opposite to surface B shall be equal or finer than Ra 3,2 µm.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The surface roughness of the ECA opposite to surface B shall be equal or finer than Ra 3,2 µm. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00084 | 4.8 The ECA shall be adapted for 6 pcs M8 flange screws described by Scania STD4435Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 4.8 The ECA shall be adapted for 6 pcs M8 flange screws described by Scania STD4435 Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00085 | P 1 Page 4.9 The ECA shall be adapted for 2 pcs 10 mm guide pins.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: P 1 Page 4.9 The ECA shall be adapted for 2 pcs 10 mm guide pins. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00086 | Figure 5Gearbox flange 4.10 The guide pin holes in the ECA shall be Ø 10,1±0.05 mm and at least 12 mm deep.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Figure 5 - Gearbox flange 4.10 The guide pin holes in the ECA shall be Ø 10,1±0.05 mm and at least 12 mm deep. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00087 | The holes shall also block the guide pin from protruding more than 14 mm from the gearbox housing.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The holes shall also block the guide pin from protruding more than 14 mm from the gearbox housing. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00088 | 4.11 The ECA shall be able to be held by the guide pins only while being exposed to the max clutch load, (req.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 4.11 The ECA shall be able to be held by the guide pins only while being exposed to the max clutch load, (req. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00089 | Surface indents in the contacts are allowed as long as the structural integrity is unaffected 4.12 The pushrod end that makes contact with the clutch lever shall be a Ø15,93±0,07 mm steel sphere.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Surface indents in the contacts are allowed as long as the structural integrity is unaffected 4.12 The pushrod end that makes contact with the clutch lever shall be a Ø15,93±0,07 mm steel sphere. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00090 | 4.13 It shall be possible to pull the pushrod 50 times with a force of 300 N without risk for it to come loose from the ECA.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 4.13 It shall be possible to pull the pushrod 50 times with a force of 300 N without risk for it to come loose from the ECA. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00091 | Alternatively it can have a loose fit in the ECA, but it shall be possible to reconnect it by pushing it back by hand.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Alternatively it can have a loose fit in the ECA, but it shall be possible to reconnect it by pushing it back by hand. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00092 | 4.14 The ECA shall allow space for external tools according to the cylinders in the 3D envelope attached.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 4.14 The ECA shall allow space for external tools according to the cylinders in the 3D envelope attached. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00093 | 4.15 The ECA shall have a window where the volume shown in Figure 6 – Snap in tool space, could pass through(See req.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: None Architecture: Engineering Toolchain Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 4.15 The ECA shall have a window where the volume shown in Figure 6 – Snap in tool space, could pass through(See req. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Architecture view: Engineering Toolchain. Mapped security capability: None Mapped feature: Engineering tooling Mapped interface: None Mapped architecture element: Engineering Toolchain Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00094 | 4.16 The ECA shall provide a support for a clutch snap in tool on the marked surface in Figure 4ISO view of 3D envelope.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: None Architecture: Engineering Toolchain Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 4.16 The ECA shall provide a support for a clutch snap in tool on the marked surface in Figure 4 - ISO view of 3D envelope. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Architecture view: Engineering Toolchain. Mapped security capability: None Mapped feature: Engineering tooling Mapped interface: None Mapped architecture element: Engineering Toolchain Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00095 | P 1 Page 4.17 The hole shall be equipped with a cover possible to assemble and disassemble at least 50 times without tools.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: P 1 Page 4.17 The hole shall be equipped with a cover possible to assemble and disassemble at least 50 times without tools. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00096 | If an interference fit is chosen, the maximum force to assemble/disassemble shall be 50 N in room temperature.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: If an interference fit is chosen, the maximum force to assemble/disassemble shall be 50 N in room temperature. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| req.10.5 | It shall still remain intac t and keep tightness after vibration testing (See req.10.5) 4.18 When the cover is assembled it shall not be possible to insert an object larger than Ø0,2 mm into the gearbox housing between the cover and ECA.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | High Not needed | DetailsFull requirement statement: It shall still remain intac t and keep tightness after vibration testing (See req.10.5) 4.18 When the cover is assembled it shall not be possible to insert an object larger than Ø0,2 mm into the gearbox housing between the cover and ECA. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00098 | Figure 6Snap in tool space 4.19 The ECA shall have a loop or similar feature where the cable can be fixated with a cable tie.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control; Supplier Development and Production Hardening | Interface: None Architecture: Engineering Toolchain Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Figure 6 - Snap in tool space 4.19 The ECA shall have a loop or similar feature where the cable can be fixated with a cable tie. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control; Supplier Development and Production Hardening. Architecture view: Engineering Toolchain. Mapped security capability: None Mapped feature: Engineering tooling Mapped interface: None Mapped architecture element: Engineering Toolchain Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00099 | The loop or Scania assembled bracket shall be located close to the centre ( ± 20 mm) of the cable section between the connector and last cable fixation point on the gearbox 4.20 The connector for communication and power shall be positioned as indicated in Figure 4 - ISO view of 3D envelope, when connected.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: Hardware Platform Status: Missing interface | Medium Not needed | DetailsFull requirement statement: The loop or Scania assembled bracket shall be located close to the centre ( ± 20 mm) of the cable section between the connector and last cable fixation point on the gearbox 4.20 The connector for communication and power shall be positioned as indicated in Figure 4 - ISO view of 3D envelope, when connected. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00100 | Details regarding actual length and positioning tolerances shall be agreed in design phase.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Details regarding actual length and positioning tolerances shall be agreed in design phase. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00101 | 4.21 If the ECA is powered up with the PP in the utmost forward position (for example when not connected to the clutch lever) it shall move AP to its utmost reversed position.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 4.21 If the ECA is powered up with the PP in the utmost forward position (for example when not connected to the clutch lever) it shall move AP to its utmost reversed position. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00102 | 4.23 The actuator shall apply a preload force for the release bearing.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 4.23 The actuator shall apply a preload force for the release bearing. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00103 | The preload force measured on the push rod shall be 150N to 250N independent of the clutch position 4.24 The pushrod position when clutch is at rest and only preload force is applied, will vary randomly within 2 mm (± 1mm from FCCP).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The preload force measured on the push rod shall be 150N to 250N independent of the clutch position 4.24 The pushrod position when clutch is at rest and only preload force is applied, will vary randomly within 2 mm (± 1mm from FCCP). Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00104 | 4.25 It must be possible to assemble the actuator independent of the lever position without any power connection.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 4.25 It must be possible to assemble the actuator independent of the lever position without any power connection. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 12 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00105 | This means that the push rod shall be possible to move by hand.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: This means that the push rod shall be possible to move by hand. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00106 | 4.26 When the clutch is fully engaged, the active control mode is position or torque control mode and there is no active request to extract the pushrod (clutch opening motion), the ECA shall not apply a force outside of limits in preload force defined in req.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 4.26 When the clutch is fully engaged, the active control mode is position or torque control mode and there is no active request to extract the pushrod (clutch opening motion), the ECA shall not apply a force outside of limits in preload force defined in req. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| req-5.10 | P 1 Page 5 Clutch engage and disengage 5.1 It shall be possible to disengage the clutch in 180ms (= Ts) with accuracy according to req 5.10,and max speed set to 125mm/s (see req 6.4) Time is measured according to Figure 7 – Max disengage time, where the dashed line is the position request as it becomes available on the CAN bus, and the full line is the actual PP.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | High Not needed | DetailsFull requirement statement: P 1 Page 5 Clutch engage and disengage 5.1 It shall be possible to disengage the clutch in 180ms (= Ts) with accuracy according to req 5.10,and max speed set to 125mm/s (see req 6.4) Time is measured according to Figure 7 – Max disengage time, where the dashed line is the position request as it becomes available on the CAN bus, and the full line is the actual PP. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 13 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00108 | This shall be measured against the maximum disengage force (See Appendix A) Figure 7 – Maximum disengage timeExpectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: This shall be measured against the maximum disengage force (See Appendix A) Figure 7 – Maximum disengage time Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 13 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| req-6.4 | P 1 Page 5.2 It shall be possible to engage the clutch in 180ms (=Ts) with accuracy according to re q.5.10, and the max speed set to 125mm/s (see req 6.4).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | High Not needed | DetailsFull requirement statement: P 1 Page 5.2 It shall be possible to engage the clutch in 180ms (=Ts) with accuracy according to re q.5.10, and the max speed set to 125mm/s (see req 6.4). Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 14 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00110 | This shall be measured against the minimum engage force (See Appendix A) Figure 8Maximum engage timeExpectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: This shall be measured against the minimum engage force (See Appendix A) Figure 8 - Maximum engage time Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 14 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00111 | P 1 Page 5.3 The clutch actuator shall report the absolute position of the current actuator stroke (AP) (Ref 14.14).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: P 1 Page 5.3 The clutch actuator shall report the absolute position of the current actuator stroke (AP) (Ref 14.14). Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 15 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00112 | 5.4 It shall also report the position that corresponds to a fully closed clutch position (FCCP), expressed in absolute position of the actuator stroke and relative to the absolute zero position (See req.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 5.4 It shall also report the position that corresponds to a fully closed clutch position (FCCP), expressed in absolute position of the actuator stroke and relative to the absolute zero position (See req. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 15 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00113 | 5.5 The clutch actuator shall be equipped with a displacement sensor measuring the movement of the push rod, (Ref 14.14) 5.6 The actuator must be able to determine the pushrod position according to the following: Accuracy (maximum difference between measured pushrod position and actual pushrod position): +/- 1.6mm.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Hardware Platform Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 5.5 The clutch actuator shall be equipped with a displacement sensor measuring the movement of the push rod, (Ref 14.14) 5.6 The actuator must be able to determine the pushrod position according to the following: Accuracy (maximum difference between measured pushrod position and actual pushrod position): +/- 1.6mm. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 15 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00114 | Range: 85mm (AP) 5.7 For each stroke that the actuator performs it shall adjust to the current wear of the clutch.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Range: 85mm (AP) 5.7 For each stroke that the actuator performs it shall adjust to the current wear of the clutch. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 15 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00115 | This means that is shall be possible to request a relative stroke from the fully closed clutch position and achieve the step accuracy as defined in req.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: This means that is shall be possible to request a relative stroke from the fully closed clutch position and achieve the step accuracy as defined in req. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 15 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00116 | The FCCP after a clutch engage shall be updated to 90% of the step within 0,2 s per mm that the FCCP have changed during the stroke.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Secure Software Update | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: The FCCP after a clutch engage shall be updated to 90% of the step within 0,2 s per mm that the FCCP have changed during the stroke. Engineering expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Engineering interpretation: Security view: Secure Software Update. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 15 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00117 | 5.9 The maximum stationary position error relative to real FCCP (i e self-adjustment error + step response error) shall be ±0.15mm.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 5.9 The maximum stationary position error relative to real FCCP (i e self-adjustment error + step response error) shall be ±0.15mm. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 15 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00118 | P 1 Page 5.10 The actuator shall move the pushrod according to the following points: Actuator maximum speed: The maximum achievable speed of the pushrod shall be at least 125 mm/s.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: P 1 Page 5.10 The actuator shall move the pushrod according to the following points: Actuator maximum speed: The maximum achievable speed of the pushrod shall be at least 125 mm/s. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 16 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00119 | The actuator shall move the pushrod at the highest possible speed, limited only by its maximum achievable speed and the maximum speed request.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The actuator shall move the pushrod at the highest possible speed, limited only by its maximum achievable speed and the maximum speed request. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 16 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00120 | 6.4) Dynamics start of movement: The requested speed (or 125mm/s, if requested speed > 125mm/s) shall be achieved within 50ms from when a new value for requested position is sent.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 6.4) Dynamics start of movement: The requested speed (or 125mm/s, if requested speed > 125mm/s) shall be achieved within 50ms from when a new value for requested position is sent. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 16 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00121 | Dynamics end of movement: The requested speed shall be kept until 2 mm from the target position.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Dynamics end of movement: The requested speed shall be kept until 2 mm from the target position. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 16 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00122 | 100ms after reaching 2 mm from target, the maximum position error should be ±0.1mm.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 100ms after reaching 2 mm from target, the maximum position error should be ±0.1mm. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 16 Classification: Not Applicable Mandatory level: Should Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| req-5.1 | Maximum overshoot is 0.2 mm When a new position is requested, but the stroke is too short to reach requested speed, the ECA shall complete the stroke in minimum time with dynamic in compliance with the req 5.1, 5.2 and this section.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Compliance Process; System Core Status: Missing security feature, interface | High Not needed | DetailsFull requirement statement: Maximum overshoot is 0.2 mm When a new position is requested, but the stroke is too short to reach requested speed, the ECA shall complete the stroke in minimum time with dynamic in compliance with the req 5.1, 5.2 and this section. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Compliance Process; System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process; System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 16 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00124 | 5.10 shall be tested with a step response test cycle, according to description and Figure 10Step response test cycle.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 5.10 shall be tested with a step response test cycle, according to description and Figure 10 - Step response test cycle. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 17 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00125 | P 1 Page 5.12 The ECA shall be able to run the 4 second test cycle in Figure 11Release frequency test continuously for 5 hours without any degradation or failure.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: P 1 Page 5.12 The ECA shall be able to run the 4 second test cycle in Figure 11 - Release frequency test continuously for 5 hours without any degradation or failure. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 18 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| req-8.1 | The test shall be done with the highest operating temperature (see req 8.1) and maximum clutch force (See Appendix A) Figure 11 - Release frequency testExpectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | High Not needed | DetailsFull requirement statement: The test shall be done with the highest operating temperature (see req 8.1) and maximum clutch force (See Appendix A) Figure 11 - Release frequency test Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 18 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00127 | Between 16V and loss of power the ECA shall hold its current position or move towards requested position without any time requirement.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Between 16V and loss of power the ECA shall hold its current position or move towards requested position without any time requirement. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 19 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00128 | The strategy shall be disc ussed and approved with Traton.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The strategy shall be disc ussed and approved with Traton. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 19 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00129 | 5.1 and 5.2) Figure 12Class B exceptions 5.14 It shall be possible to keep the clutch disengaged continuously without risk of loss of function for 120 min.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Application Software Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 5.1 and 5.2) Figure 12 - Class B exceptions 5.14 It shall be possible to keep the clutch disengaged continuously without risk of loss of function for 120 min. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 19 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00130 | This shall be measured against the maximum disengage force (Appendix A) and an highest operating temperature (see req.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: This shall be measured against the maximum disengage force (Appendix A) and an highest operating temperature (see req. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 19 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00131 | P 1 Page 6 SW functionality 6.1 TB4684 shall be applied.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: P 1 Page 6 SW functionality 6.1 TB4684 shall be applied. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 20 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00132 | It shall be followed to its full extent.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: It shall be followed to its full extent. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 20 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00133 | When requesting Absolute Position Control the actuator shall move to the actuator position defined by the Requested Position (RP).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: When requesting Absolute Position Control the actuator shall move to the actuator position defined by the Requested Position (RP). Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 21 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00134 | Specific cases shall be approved with Traton.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Specific cases shall be approved with Traton. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 21 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00135 | Control mode Absolute position 0x01 6.3.2 When requesting Relative Position Control (RPC) the actuator shall move to an offset that corresponds to the Requested Position from the Fully Closed Clutch Position (FCCP).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Control mode Absolute position 0x01 6.3.2 When requesting Relative Position Control (RPC) the actuator shall move to an offset that corresponds to the Requested Position from the Fully Closed Clutch Position (FCCP). Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 21 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00136 | Control mode Relative position 0x02 6.3.3 When requesting Torque Control (TC) the actuator shall actuate the requested motor torque.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Control mode Relative position 0x02 6.3.3 When requesting Torque Control (TC) the actuator shall actuate the requested motor torque. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 21 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00137 | 6.3.4 When requesting Test Mode, the actuator shall perform tests to detect latent faults.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 6.3.4 When requesting Test Mode, the actuator shall perform tests to detect latent faults. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 22 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00138 | ECA behavior and additional requirements for this mode can be found in (Ref 14.16) Control mode Test mode 0x04 6.3.5 When this Control Mode is sent the actuator shall behave as if the power supply was cut with aspect to control of the actuator.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: ECA behavior and additional requirements for this mode can be found in (Ref 14.16) Control mode Test mode 0x04 6.3.5 When this Control Mode is sent the actuator shall behave as if the power supply was cut with aspect to control of the actuator. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 22 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00139 | CAN communication shall still be active.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: CAN communication shall still be active. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 22 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00140 | If the actuator can move faster than this value it shall be controlled in a such way that it does not exceed this limit.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: If the actuator can move faster than this value it shall be controlled in a such way that it does not exceed this limit. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 22 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00141 | 6.5 Self-adjustment The self-adjustment signal defines the restrictions of how the FCCP shall be identified.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: 6.5 Self-adjustment The self-adjustment signal defines the restrictions of how the FCCP shall be identified. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 22 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| req-6.3 | The signal is valid during Control Modes RPC and TC(see req 6.3).Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Secure Communication and Boundary Control | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: The signal is valid during Control Modes RPC and TC(see req 6.3). Engineering expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Engineering interpretation: Security view: Secure Communication and Boundary Control. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 22 Classification: Reclassified as Informational Mandatory level: Informational Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00143 | The value of the FCCP shall be reported via CAN(Ref 14.14) Req.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: The value of the FCCP shall be reported via CAN(Ref 14.14) Req. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 22 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00144 | The value shall be frozen at the last identified position and used for RPC.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The value shall be frozen at the last identified position and used for RPC. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 22 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00145 | 6.6.1 When low accuracy mode is requested, the maximum push rod position(PP) error can be ±0.5mm Accuracy mode Low accuracy 0x0 6.6.2 Accuracy according to 5.10 shall be fulfilled.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: 6.6.1 When low accuracy mode is requested, the maximum push rod position(PP) error can be ±0.5mm Accuracy mode Low accuracy 0x0 6.6.2 Accuracy according to 5.10 shall be fulfilled. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 23 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00146 | Message contents to be agreed with Traton 6.9 ECA identification number: The ECA shall report a unique ECA individual identification number 6.10 Supplier code: The ECA shall report supplier code 5 via CAN.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Secure Communication and Boundary Control; Supplier Development and Production Hardening | Interface: External Interfaces; OEM/Customer Review Interface Architecture: External Interfaces; OEM/Customer Review Interface Status: Complete | Medium Needed | DetailsFull requirement statement: Message contents to be agreed with Traton 6.9 ECA identification number: The ECA shall report a unique ECA individual identification number 6.10 Supplier code: The ECA shall report supplier code 5 via CAN. Engineering expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Engineering interpretation: Security view: Secure Communication and Boundary Control; Supplier Development and Production Hardening. Interface view: External Interfaces; OEM/Customer Review Interface. Architecture view: External Interfaces; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: External interfaces Mapped interface: External Interfaces; OEM/Customer Review Interface Mapped architecture element: External Interfaces; OEM/Customer Review Interface Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 23 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00147 | 6.11 SW number: The ECA shall report a complete SW version number.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 6.11 SW number: The ECA shall report a complete SW version number. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 23 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00148 | 6.12 HW number: The ECA shall report a complete HW version number.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 6.12 HW number: The ECA shall report a complete HW version number. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 23 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| req-6.20 | 6.13 Error State DiagnosticESD and Error State Action - ESA The ECA shall send a bit field via CAN containing errors present Additionally, see req 6.20, req 6.22 ,req.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security | Interface: None Architecture: Security Services Status: Missing interface | High Not needed | DetailsFull requirement statement: 6.13 Error State Diagnostic - ESD and Error State Action - ESA The ECA shall send a bit field via CAN containing errors present Additionally, see req 6.20, req 6.22 ,req. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security. Architecture view: Security Services. Mapped security capability: Diagnostic security Mapped feature: Diagnostic security Mapped interface: None Mapped architecture element: Security Services Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 23 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00150 | ESA definition( Ref 14.16) The supplier shall provide documentation for the ESD bits and related faults .Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Cybersecurity Evidence and DIA; Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: ESA definition( Ref 14.16) The supplier shall provide documentation for the ESD bits and related faults . Engineering expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Engineering interpretation: Security view: Cybersecurity Evidence and DIA; Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 23 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00151 | 6.14 System state The ECA shall report its current System State.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 6.14 System state The ECA shall report its current System State. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 23 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00152 | 6.14.1 Boot Mode If the actuator is in boot mode, 0x00 shall be reported as active state.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Boot and Application State Control | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 6.14.1 Boot Mode If the actuator is in boot mode, 0x00 shall be reported as active state. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Boot and Application State Control. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 24 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00153 | 0x0 6.14.2 Absolute Position Control This value shall be sent when the ECA is actuating Absolute Position Control.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 0x0 6.14.2 Absolute Position Control This value shall be sent when the ECA is actuating Absolute Position Control. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 24 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00154 | 0x1 6.14.3 Relative Position Control This value shall be sent when the ECA is actuating Relative Position Control.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 0x1 6.14.3 Relative Position Control This value shall be sent when the ECA is actuating Relative Position Control. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 24 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00155 | 0x2 6.14.4 Torque Control This value shall be sent when the ECA is actuating Torque Control.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 0x2 6.14.4 Torque Control This value shall be sent when the ECA is actuating Torque Control. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 24 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00156 | 0x4 6.14.5 Self-Adjustment This value shall be sent when the ECA is performing a Self-Adjustment procedure that is not part of a RPC or TC request (i.e.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 0x4 6.14.5 Self-Adjustment This value shall be sent when the ECA is performing a Self-Adjustment procedure that is not part of a RPC or TC request (i.e. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 24 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00157 | 0x5 6.14.6 Initializing This value shall be sent when the ECA is performing its initiation routine and is not yet available for control.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 0x5 6.14.6 Initializing This value shall be sent when the ECA is performing its initiation routine and is not yet available for control. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 24 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00158 | 0xA 6.14.7 Shut down This value shall be sent when the ECA is performing its shut down routing and is not available for control.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 0xA 6.14.7 Shut down This value shall be sent when the ECA is performing its shut down routing and is not available for control. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 24 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00159 | 0xB 6.14.8 Debug / Test This value shall be sent when the actuator is in debug or test control state.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 0xB 6.14.8 Debug / Test This value shall be sent when the actuator is in debug or test control state. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 24 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00160 | 0xC 6.14.9 Motor Brake Simulation This value shall be sent when the actuator is performing a motor brake simulation.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 0xC 6.14.9 Motor Brake Simulation This value shall be sent when the actuator is performing a motor brake simulation. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 24 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00161 | P 1 Page 6.15 System Temperature The ECA shall report the current system temperature.(Ref 14.14) 6.16 Torque Feedback The ECA shall calculate and report the actuator motor torque.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: P 1 Page 6.15 System Temperature The ECA shall report the current system temperature.(Ref 14.14) 6.16 Torque Feedback The ECA shall calculate and report the actuator motor torque. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 25 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00162 | (Ref 14.14) 6.17 Current feedback The ECA shall report the current for each phase of the actuator.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: (Ref 14.14) 6.17 Current feedback The ECA shall report the current for each phase of the actuator. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 25 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00163 | These values shall be calculated using a moving mean filter.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: These values shall be calculated using a moving mean filter. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 25 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00164 | The filter time shall equal the update frequency .Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Secure Software Update | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: The filter time shall equal the update frequency . Engineering expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Engineering interpretation: Security view: Secure Software Update. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 25 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00165 | (Ref 14.14) 6.18 Supply Voltage Feedback The ECA shall report the current system voltage.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: (Ref 14.14) 6.18 Supply Voltage Feedback The ECA shall report the current system voltage. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 25 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| Req.ID-Description-6.19.1 | (input voltage) (Ref 14.14) 6.19 Operational data The following operational data deemed important to store (req.6.16.1, req 6.16.2) (Ref 14.14) Req.ID Description 6.19.1 Operational hours: The ECA shall store and report its accumulated operational hours.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | High Not needed | DetailsFull requirement statement: (input voltage) (Ref 14.14) 6.19 Operational data The following operational data deemed important to store (req.6.16.1, req 6.16.2) (Ref 14.14) Req.ID Description 6.19.1 Operational hours: The ECA shall store and report its accumulated operational hours. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 25 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00167 | 6.19.2 Total travelled length: The ECA shall report its accumulated lifetime travel length.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 6.19.2 Total travelled length: The ECA shall report its accumulated lifetime travel length. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 25 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00168 | 6.20 Diagnosis: CVS120 shall be applied (Ref 14.12).Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Cybersecurity Evidence and DIA | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 6.20 Diagnosis: CVS120 shall be applied (Ref 14.12). Engineering expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Engineering interpretation: Security view: Cybersecurity Evidence and DIA. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 25 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00169 | 6.21 Cyber Security: Cybersecurity shall be considered through a separate process with the latest Traton workflow in mind.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Cybersecurity requirement handling | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 6.21 Cyber Security: Cybersecurity shall be considered through a separate process with the latest Traton workflow in mind. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Cybersecurity requirement handling. Architecture view: Security Services. Mapped security capability: Cybersecurity requirement handling Mapped feature: Cybersecurity requirement handling Mapped interface: None Mapped architecture element: Security Services Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 25 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| Req.ID-Description-6.22.1 | Req.ID Description 6.22.1 Wrong rotation direction 6.22.2 Short circuit / open load on the phases 6.22.3 Motor rotation feedback, short circuit / open loadExpectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | None | Interface: None Architecture: None Status: Missing security feature, interface, architecture | Medium Needed | DetailsFull requirement statement: Req.ID Description 6.22.1 Wrong rotation direction 6.22.2 Short circuit / open load on the phases 6.22.3 Motor rotation feedback, short circuit / open load Engineering expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Engineering interpretation: Traceability needs review before this requirement can be used as design evidence. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 25 Classification: Reclassified as Informational Mandatory level: Informational Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00171 | P 1 Page 6.22.4 Positions sensor short circuit / open load (if used) 6.22.5 Watchdog error 6.22.6 Low voltage 30 6.22.7 CAN-timeout (stored and sent when possible) 6.22.8 High temperature/current consumption (system needs to indicate abnormal usage that can damage the device), indicate a self-protective mode (if applicable) 6.22.9 Error on temperature sensor 6.22.10 High friction in mechanical system 6.22.11 Other electrical HW errorExpectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: P 1 Page 6.22.4 Positions sensor short circuit / open load (if used) 6.22.5 Watchdog error 6.22.6 Low voltage 30 6.22.7 CAN-timeout (stored and sent when possible) 6.22.8 High temperature/current consumption (system needs to indicate abnormal usage that can damage the device), indicate a self-protective mode (if applicable) 6.22.9 Error on temperature sensor 6.22.10 High friction in mechanical system 6.22.11 Other electrical HW error Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 26 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ-AUTO-00172 | P 1 Page 6.23 Validation and Invalidation: The reported ESD must be able to be validated and invalidated.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: P 1 Page 6.23 Validation and Invalidation: The reported ESD must be able to be validated and invalidated. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 27 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00173 | 6.24 Diagnosis tracking: The gearbox control unit(TCU) shall be responsible for setting DTCs based on received notifications from ECA via ESD, including time-stamps, occurrence counters etc.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Cybersecurity Evidence and DIA | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 6.24 Diagnosis tracking: The gearbox control unit(TCU) shall be responsible for setting DTCs based on received notifications from ECA via ESD, including time-stamps, occurrence counters etc. Engineering expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Engineering interpretation: Security view: Cybersecurity Evidence and DIA. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 27 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00174 | If higher resolution is required for the supplier to properly troubleshoot any individual occurrence, then the ECA is responsible for storing these parameters internally.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: If higher resolution is required for the supplier to properly troubleshoot any individual occurrence, then the ECA is responsible for storing these parameters internally. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 27 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00175 | Internally stored parameters may be accessible only using supplier defined tools .Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Needed | DetailsFull requirement statement: Internally stored parameters may be accessible only using supplier defined tools . Engineering expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Engineering interpretation: Security view: Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 27 Classification: Reclassified as Constraint Mandatory level: May Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00176 | 6.25 Data logging: Any data logged or stored shall be agreed upon together with Traton.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Security Logging and Event Handling | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 6.25 Data logging: Any data logged or stored shall be agreed upon together with Traton. Engineering expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Engineering interpretation: Security view: Security Logging and Event Handling. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 27 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00177 | 6.26 Data storage: When storing data in the device, the supplier shall take measures to prevent corruption of data which can occur for example when suffering power loss during read or write cycles.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Secure Communication and Boundary Control; Security Logging and Event Handling; Supplier Development and Production Hardening | Interface: External Interfaces; OEM/Customer Review Interface Architecture: External Interfaces; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: 6.26 Data storage: When storing data in the device, the supplier shall take measures to prevent corruption of data which can occur for example when suffering power loss during read or write cycles. Engineering expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Engineering interpretation: Security view: Secure Communication and Boundary Control; Security Logging and Event Handling; Supplier Development and Production Hardening. Interface view: External Interfaces; OEM/Customer Review Interface. Architecture view: External Interfaces; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: External interfaces Mapped interface: External Interfaces; OEM/Customer Review Interface Mapped architecture element: External Interfaces; OEM/Customer Review Interface Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 27 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00178 | The supplier shall also ensure that systems are in place that ensure that data corruption is handled without loss of data, or loss of function.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: The supplier shall also ensure that systems are in place that ensure that data corruption is handled without loss of data, or loss of function. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: Application Software; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: Application Software; OEM/Customer Review Interface Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 27 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00179 | 6.27 Calibration: There shall only be one calibration set of the ECA that is delivered to Traton, i.e, the calibration shall not be dependent of installation variants.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 6.27 Calibration: There shall only be one calibration set of the ECA that is delivered to Traton, i.e, the calibration shall not be dependent of installation variants. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 27 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00180 | 6.28 Reset: It shall be possible to reset the ECA application with a power off/on cycle after all functional safety events.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Secure Boot and Application State Control; Security Logging and Event Handling | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 6.28 Reset: It shall be possible to reset the ECA application with a power off/on cycle after all functional safety events. Engineering expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Engineering interpretation: Security view: Secure Boot and Application State Control; Security Logging and Event Handling. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 27 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00181 | ID General electrical requirements 7.1 The electrical design must ensure that an internal short circuit through one of H -bridges (“shoot- through”) is avoided.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: ID General electrical requirements 7.1 The electrical design must ensure that an internal short circuit through one of H -bridges (“shoot- through”) is avoided. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 28 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00182 | 7.2 Short circuit protection shall be implemented by hardware.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Hardware Platform Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 7.2 Short circuit protection shall be implemented by hardware. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 28 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00183 | 7.3 A safe boot sequence must be set to prevent unwanted or undefined behavior during or after loss of power, or corruption of stored data.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Secure Boot and Application State Control; Security Logging and Event Handling | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 7.3 A safe boot sequence must be set to prevent unwanted or undefined behavior during or after loss of power, or corruption of stored data. Engineering expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Engineering interpretation: Security view: Secure Boot and Application State Control; Security Logging and Event Handling. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 28 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00184 | 7.4 A safe memory read/write sequence must also be implemented during actuator movement, in order to ensure safe and predictable behavior during operation, or in case of power lo ss.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Hardware Platform Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 7.4 A safe memory read/write sequence must also be implemented during actuator movement, in order to ensure safe and predictable behavior during operation, or in case of power lo ss. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 28 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| Req.ID-Connector-Requirements-7.5 | Req.ID Connector Requirements 7.5 All external electrical connectors shall be geometrically coded.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Hardware Platform Status: Missing security feature, interface | High Not needed | DetailsFull requirement statement: Req.ID Connector Requirements 7.5 All external electrical connectors shall be geometrically coded. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 28 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00186 | If internal components are included in repair kits, the internal electrical connectors shall also be geometrically coded.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: If internal components are included in repair kits, the internal electrical connectors shall also be geometrically coded. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 28 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00187 | 7.8 ECU tab headers shall comply with TB1787.(Ref 14.6) 7.9 ECU tab headers shall be made of self-extinguishing materials (i.e.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Hardware Platform Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 7.8 ECU tab headers shall comply with TB1787.(Ref 14.6) 7.9 ECU tab headers shall be made of self-extinguishing materials (i.e. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 28 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00188 | All power used by the ECA shall be taken from this battery connection.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: All power used by the ECA shall be taken from this battery connection. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 29 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00189 | The ground shall not be DC connected to the ECA housing.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The ground shall not be DC connected to the ECA housing. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 29 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00190 | 7.17 Umax:- 32/36/48 A Specific test relations TBD 7.18 Umin: 16 - - V CVS41 limits may go below this value.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | None | Interface: None Architecture: None Status: Missing security feature, interface, architecture | Medium Needed | DetailsFull requirement statement: 7.17 Umax: - - 32/36/48 A Specific test relations TBD 7.18 Umin: 16 - - V CVS41 limits may go below this value. Engineering expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Engineering interpretation: Traceability needs review before this requirement can be used as design evidence. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 29 Classification: Reclassified as Assumption Mandatory level: May Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00191 | 7.23 Quiescent current: According to CVS41 (Ref 14.2), must be met independent of input and output conditions.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 7.23 Quiescent current: According to CVS41 (Ref 14.2), must be met independent of input and output conditions. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 30 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00192 | It shall be used to control the power up sequence to the µP.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: It shall be used to control the power up sequence to the µP. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 31 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00193 | The Wake-up signal shall also be connected to a digital input on the µP.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: The Wake-up signal shall also be connected to a digital input on the µP. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 31 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00194 | Special precautions shall be taken to prevent direct connection between Wake-up and 30 in case of a single failure.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Security Logging and Event Handling | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Special precautions shall be taken to prevent direct connection between Wake-up and 30 in case of a single failure. Engineering expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Engineering interpretation: Security view: Security Logging and Event Handling. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 31 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00195 | After the wake-up line goes to high state: The ECA shall communicate on the CAN line within 250ms in case of a normal start -up The ECA shall be ready to open the clutch within 350ms in case of a normal start -up The ECA shall be ready to open the clutch as soon as possible after necessary movements in case of an abnormal start-up.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: After the wake-up line goes to high state: The ECA shall communicate on the CAN line within 250ms in case of a normal start -up The ECA shall be ready to open the clutch within 350ms in case of a normal start -up The ECA shall be ready to open the clutch as soon as possible after necessary movements in case of an abnormal start-up. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 31 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00196 | After movement and reset, the ECA shall communicate on the CAN line within 250ms After movement and reset, the ECA shall be ready to open the clutch within 400ms In the case if the wake-up goes "high" at the same time as U30 signal the ECA should be ready to open the clutch within 3 seconds.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Boot and Application State Control; Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: After movement and reset, the ECA shall communicate on the CAN line within 250ms After movement and reset, the ECA shall be ready to open the clutch within 400ms In the case if the wake-up goes "high" at the same time as U30 signal the ECA should be ready to open the clutch within 3 seconds. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Boot and Application State Control; Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 31 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00197 | Definition ready to open clutch: The actuator position shall be between FCCP and FCCP -3mm and the ECA is capable to move to disengaged clutch directly when requeste d.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Definition ready to open clutch: The actuator position shall be between FCCP and FCCP -3mm and the ECA is capable to move to disengaged clutch directly when requeste d. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 31 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00198 | Redundancies due improper shutdown shall be aligned with Traton.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Redundancies due improper shutdown shall be aligned with Traton. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 31 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00199 | If a signal for disengaging the clutch is received the ECA shall actuate the request regardless of CAN-request.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: If a signal for disengaging the clutch is received the ECA shall actuate the request regardless of CAN-request. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 33 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00200 | Any watchdog circuit shall have no influence on the CAN bus.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: Any watchdog circuit shall have no influence on the CAN bus. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 34 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00201 | The CAN front end shall be designed to comply with TB1905 (Ref 14.3), with the following additional information in this chapter.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: The CAN front end shall be designed to comply with TB1905 (Ref 14.3), with the following additional information in this chapter. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 34 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00202 | 7.35 The controller and transceiver shall be CAN FD ready.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: 7.35 The controller and transceiver shall be CAN FD ready. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 34 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00203 | 7.36 Termination resistance:2 x 60 - Ω 1% resistors shall be used 7.37 Baud rate: 250 500 1000 kbit/s Flashing in production shall be possible with 1000kbit/s.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Secure Software Update; Supplier Development and Production Hardening | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 7.36 Termination resistance: - 2 x 60 - Ω 1% resistors shall be used 7.37 Baud rate: 250 500 1000 kbit/s Flashing in production shall be possible with 1000kbit/s. Engineering expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Engineering interpretation: Security view: Secure Software Update; Supplier Development and Production Hardening. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 34 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00204 | ID Requirements 7.39 Note: The layout shall always be present on the PCB and the supplier must be flexible in changing/removing the CAN related components in this section.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control; Supplier Development and Production Hardening | Interface: External Interfaces; OEM/Customer Review Interface Architecture: External Interfaces; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: ID Requirements 7.39 Note: The layout shall always be present on the PCB and the supplier must be flexible in changing/removing the CAN related components in this section. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control; Supplier Development and Production Hardening. Interface view: External Interfaces; OEM/Customer Review Interface. Architecture view: External Interfaces; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: External interfaces Mapped interface: External Interfaces; OEM/Customer Review Interface Mapped architecture element: External Interfaces; OEM/Customer Review Interface Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 35 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00205 | The components shall not be populated by default.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The components shall not be populated by default. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 35 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00206 | The CAN front end shall be designed to comply with TB1905.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: The CAN front end shall be designed to comply with TB1905. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 35 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00207 | The quality of the wire bonding and position shall be properly analyzed.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The quality of the wire bonding and position shall be properly analyzed. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 36 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00208 | The material shall be lead free and of ”high temperatures solder type”.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The material shall be lead free and of ”high temperatures solder type”. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 36 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00209 | The melting point of the soldering material and the composition of the soldering material shall be declared by supplier.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: The melting point of the soldering material and the composition of the soldering material shall be declared by supplier. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 36 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00210 | The PCB must be supported and must not bent in any direction during the process.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Compliance Process Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The PCB must be supported and must not bent in any direction during the process. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 36 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00211 | Conformal coating or lacquer shall cover the entire PCB and all solder joints.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Conformal coating or lacquer shall cover the entire PCB and all solder joints. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 36 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00212 | The layout of the PCB, including component placement, shall take the applying of conformal coating into consideration so that the aforementioned requirement can be met.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: The layout of the PCB, including component placement, shall take the applying of conformal coating into consideration so that the aforementioned requirement can be met. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 36 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00213 | shall be specified in the initial offer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: shall be specified in the initial offer. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 36 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00214 | The conformal coating process and materials shall apply to the latest versions of IPC/EIA J-STD-001 (with applicable standards as e.g.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Compliance Process Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The conformal coating process and materials shall apply to the latest versions of IPC/EIA J-STD-001 (with applicable standards as e.g. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 36 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00215 | HDBK-001, IPC-CC-830 and HDBK-830) and the visual appearance of the final coating shall be consistent with the latest version of IPC-A-610.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: HDBK-001, IPC-CC-830 and HDBK-830) and the visual appearance of the final coating shall be consistent with the latest version of IPC-A-610. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 36 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00216 | Water based and silicone lacquers shall not be used.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Water based and silicone lacquers shall not be used. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 36 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00217 | 7.45 Ventilation: The air inside the electronics enclosure shall be ventilated with the use of a membrane.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 7.45 Ventilation: The air inside the electronics enclosure shall be ventilated with the use of a membrane. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 36 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00218 | The following requirements shall be fulfilled: The unit shall withstand the salt-spray environment, according to CVS40 §6.1.6, without clogging of the membrane.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Security Logging and Event Handling | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: The following requirements shall be fulfilled: The unit shall withstand the salt-spray environment, according to CVS40 §6.1.6, without clogging of the membrane. Engineering expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Engineering interpretation: Security view: Security Logging and Event Handling. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 36 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00219 | The membrane shall be placed so that it is protected against blunt force, falling dust and dripping salt-water.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The membrane shall be placed so that it is protected against blunt force, falling dust and dripping salt-water. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 36 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00220 | The design shall be made to prevent accumulation of water on top of the membrane, or in the cavity of the membrane.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Security Logging and Event Handling | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: The design shall be made to prevent accumulation of water on top of the membrane, or in the cavity of the membrane. Engineering expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Engineering interpretation: Security view: Security Logging and Event Handling. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 36 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00221 | 7.46 Forbidden components: BGA capsule in any form must not be used.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 7.46 Forbidden components: BGA capsule in any form must not be used. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 36 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00222 | Tantalum capacitors must not be used Serial resistors on power supply circuits must not be used.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Tantalum capacitors must not be used Serial resistors on power supply circuits must not be used. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 36 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00223 | 8.3 The clutch actuator shall withstand 6 500 000 actuations with the test cycle described in Appendix B.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 8.3 The clutch actuator shall withstand 6 500 000 actuations with the test cycle described in Appendix B. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 38 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00224 | 8.4 Six consecutive units shall run past 6.5M actuations at the supplier, and continue to end of life.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: 8.4 Six consecutive units shall run past 6.5M actuations at the supplier, and continue to end of life. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 38 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00225 | Three consecutive units shall run past 6.5M actuations at Scania, and continue to end of life.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Three consecutive units shall run past 6.5M actuations at Scania, and continue to end of life. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 38 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00226 | 8.5 The ECA must be maintenance free over the whole life time.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 8.5 The ECA must be maintenance free over the whole life time. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 38 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00227 | 8.6 Failure rate for ECU and electronics shall be less than: 0ppm @ “0” km 200ppm/year during year 1-5 400ppm/year during year 6-10 1000ppm/year during year 11-15 8.7 External vulnerable components might need to be replaceable.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Hardware Platform Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 8.6 Failure rate for ECU and electronics shall be less than: 0ppm @ “0” km 200ppm/year during year 1-5 400ppm/year during year 6-10 1000ppm/year during year 11-15 8.7 External vulnerable components might need to be replaceable. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 38 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00228 | Spare parts or repair kits shall be defined together in agreement.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Spare parts or repair kits shall be defined together in agreement. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 38 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00229 | 4.17) shall be provided as a spare part.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 4.17) shall be provided as a spare part. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 38 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00230 | 8.9 In a situation where the ECA has jammed, and is holding the clutch open, it shall be possible to remove the clutch force by following an instruction documented on the ECA drawing.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 8.9 In a situation where the ECA has jammed, and is holding the clutch open, it shall be possible to remove the clutch force by following an instruction documented on the ECA drawing. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 38 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00231 | ID Recycling and environmental impact 9.1 The ECA shall fulfil the requirements stated in STD3868.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: ID Recycling and environmental impact 9.1 The ECA shall fulfil the requirements stated in STD3868. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 39 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00232 | Out of a recycling and environmental perspective the following standards shall be taken under consideration in addition to CVS55(Ref 14.32): STD4158, Chemical substances which shall not be used – Scania Black list.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Out of a recycling and environmental perspective the following standards shall be taken under consideration in addition to CVS55(Ref 14.32): STD4158, Chemical substances which shall not be used – Scania Black list. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 39 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00233 | The different parts of the housing shall be marked according to material content.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The different parts of the housing shall be marked according to material content. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 39 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00234 | The ECA shall be lead free.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The ECA shall be lead free. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 39 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00235 | ID ADR Requirements 9.2 All included parts shall fulfil applicable sections of Part 9 in Annex B to the latest ADR ,as applicable at the time of type approval.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Missing security feature | Medium Not needed | DetailsFull requirement statement: ID ADR Requirements 9.2 All included parts shall fulfil applicable sections of Part 9 in Annex B to the latest ADR ,as applicable at the time of type approval. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 39 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00236 | For type approval, the vehicle and its components shall comply with ECE Regulation No.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Missing security feature | Medium Not needed | DetailsFull requirement statement: For type approval, the vehicle and its components shall comply with ECE Regulation No. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 39 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00237 | P 1 Page 10 Environmental and electrical testing 10.1 The ECA must fulfil the general requirements for Electronic Control Units (ECUs), which are stated in CVS40 (Ref 14.1) and CVS41 (Ref 14.2).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: P 1 Page 10 Environmental and electrical testing 10.1 The ECA must fulfil the general requirements for Electronic Control Units (ECUs), which are stated in CVS40 (Ref 14.1) and CVS41 (Ref 14.2). Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 40 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00238 | 10.2 The ECA must not be dependent on software for protection against requirements stated in CVS40 (Ref 14.1) and CVS41 (Ref 14.2).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Application Software Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 10.2 The ECA must not be dependent on software for protection against requirements stated in CVS40 (Ref 14.1) and CVS41 (Ref 14.2). Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 40 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00239 | CAN communication shall not be affected.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: CAN communication shall not be affected. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 40 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00240 | Memory functions shall remain Class A.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Hardware Platform Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Memory functions shall remain Class A. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 40 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00241 | Accepted behaviour in this case shall be agreed upon between Traton and Supplier.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: Accepted behaviour in this case shall be agreed upon between Traton and Supplier. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 40 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00242 | P 1 Page 10.4 For this unit, the following definitions of test procedure I and test procedure II shall be used: Test procedure I A comprehensive test where all functional requirements are verified.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: P 1 Page 10.4 For this unit, the following definitions of test procedure I and test procedure II shall be used: Test procedure I A comprehensive test where all functional requirements are verified. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 41 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00243 | This test shall be performed before and after exposure.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: This test shall be performed before and after exposure. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 41 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00244 | Test procedure I (See Figure 17Test procedure I) shall at least contain: - Full stroke to evaluate speed - Staircase to evaluate accuracy - Power loss to evaluate safety Figure 17 - Test procedure I Test procedure II A reduced function test where the fundamental requirements are verified.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Application Software Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Test procedure I (See Figure 17 - Test procedure I) shall at least contain: - Full stroke to evaluate speed - Staircase to evaluate accuracy - Power loss to evaluate safety Figure 17 - Test procedure I Test procedure II A reduced function test where the fundamental requirements are verified. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 41 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00245 | This test shall be possible to perform during exposure.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: This test shall be possible to perform during exposure. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 41 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00246 | Reduced versions of test procedure II may be agreed and used during various tests.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | None | Interface: None Architecture: None Status: Missing security feature, interface, architecture | Medium Needed | DetailsFull requirement statement: Reduced versions of test procedure II may be agreed and used during various tests. Engineering expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Engineering interpretation: Traceability needs review before this requirement can be used as design evidence. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 41 Classification: Reclassified as Assumption Mandatory level: May Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00247 | P 1 Page 10.5.11 CVS40 §5.5 TC-05 Temperature cycle test Tmax.tes= +120°C, Tmin.test=-40°C Y 10.5.12 CVS40 §5.6 TC-06 Thermal shock Y 10.5.13 CVS40 §5.7 TC-07 Splash water test Y 10.5.14 CVS40 §5.8 TC-08 Ice water / hot air shock test It is not allowed to use a snorkel to pass this test Y 10.5.15 CVS40 §5.9 TC-09 Leakage search test Y 10.5.16 CVS40 §5.10 TC-10 Ingress protection The ECA shall also fulfil IP54 without mounted connectors.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: P 1 Page 10.5.11 CVS40 §5.5 TC-05 Temperature cycle test Tmax.tes= +120°C, Tmin.test=-40°C Y 10.5.12 CVS40 §5.6 TC-06 Thermal shock Y 10.5.13 CVS40 §5.7 TC-07 Splash water test Y 10.5.14 CVS40 §5.8 TC-08 Ice water / hot air shock test It is not allowed to use a snorkel to pass this test Y 10.5.15 CVS40 §5.9 TC-09 Leakage search test Y 10.5.16 CVS40 §5.10 TC-10 Ingress protection The ECA shall also fulfil IP54 without mounted connectors. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 43 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00248 | tab headers) shall be made of self- extinguishing materials (i.e.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: tab headers) shall be made of self- extinguishing materials (i.e. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 44 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00249 | P 1 Page 10.7.14 CVS46 §4.6.6 Test LFM: Low Frequency Magnetic Y 10.7.15 CVS46 §4.7 Test VCB CTE N 10.7.16 CVS46 §4.8 Test VCB AN and VCB CP N 10.7.17 CVS46 §4.9 Test C-VCB-VCA N 10.7.18 CVS46 §4.10 Test TSUP VCB A N 10.7.19 CVS46 §4.11 Test TSUP VCB B N 10.7.20 CVS46 §4.12 Test VCB Surge N 10.7.21 CVS46 §4.13 Test VCB Burst N 10.7.22 CVS46 §4.14 Test VCB Charging mode N 10.7.23 CVS46 §4.15 Test ESD: Immunity to electrostatic discharge (ESD) Y 10.7.24 CVS46 §4.15.1 Test ESDD: Direct Discharge, Powered up Y 10.7.25 CVS46 §4.15.2 Test ESDI: Indirect Discharge (Powered up) Y 10.7.26 CVS46 §4.15.3 Test ESDH: ESD Handling, Component not energised Y 10.7.27 CVS46 §5.1 Vehicle test ESD Traton performs Vehicle test, Traton may need support from supplier with any issues originating from the component.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: P 1 Page 10.7.14 CVS46 §4.6.6 Test LFM: Low Frequency Magnetic Y 10.7.15 CVS46 §4.7 Test VCB CTE N 10.7.16 CVS46 §4.8 Test VCB AN and VCB CP N 10.7.17 CVS46 §4.9 Test C-VCB-VCA N 10.7.18 CVS46 §4.10 Test TSUP VCB A N 10.7.19 CVS46 §4.11 Test TSUP VCB B N 10.7.20 CVS46 §4.12 Test VCB Surge N 10.7.21 CVS46 §4.13 Test VCB Burst N 10.7.22 CVS46 §4.14 Test VCB Charging mode N 10.7.23 CVS46 §4.15 Test ESD: Immunity to electrostatic discharge (ESD) Y 10.7.24 CVS46 §4.15.1 Test ESDD: Direct Discharge, Powered up Y 10.7.25 CVS46 §4.15.2 Test ESDI: Indirect Discharge (Powered up) Y 10.7.26 CVS46 §4.15.3 Test ESDH: ESD Handling, Component not energised Y 10.7.27 CVS46 §5.1 Vehicle test ESD Traton performs Vehicle test, Traton may need support from supplier with any issues originating from the component. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 47 Classification: Needs Manual Markdown Correction Mandatory level: May Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ-AUTO-00250 | Y 10.7.28 CVS46 §5.2 Vehicle test RE: Emitted interference of the complete vehicle Y 10.7.29 CVS46 §5.2.1 Vehicle test RE: Protection of receivers outside the vehicle Y 10.7.30 CVS46 §5.2.2 Vehicle test RE: Self- interference Y 10.7.31 CVS46 §5.3 Vehicle test charging: Vehicle in the AC charging mode N 10.7.32 CVS46 §5.3.1 Vehicle test: AC charging: Vehicle in AC charging mode N 10.7.33 CVS46 §5.3.2 Vehicle test: DC charging: Vehicle in DC charging mode N 10.7.34 CVS46 §5.4 Vehicle test RI: Immunity of vehicles to radiated fields Traton performs Vehicle test, Traton may need support from supplier with Y 10.7.35 CVS46 §5.4.1 Vehicle test RI: External interference sources YExpectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Cybersecurity Evidence and DIA; Supplier Development and Production Hardening | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: Y 10.7.28 CVS46 §5.2 Vehicle test RE: Emitted interference of the complete vehicle Y 10.7.29 CVS46 §5.2.1 Vehicle test RE: Protection of receivers outside the vehicle Y 10.7.30 CVS46 §5.2.2 Vehicle test RE: Self- interference Y 10.7.31 CVS46 §5.3 Vehicle test charging: Vehicle in the AC charging mode N 10.7.32 CVS46 §5.3.1 Vehicle test: AC charging: Vehicle in AC charging mode N 10.7.33 CVS46 §5.3.2 Vehicle test: DC charging: Vehicle in DC charging mode N 10.7.34 CVS46 §5.4 Vehicle test RI: Immunity of vehicles to radiated fields Traton performs Vehicle test, Traton may need support from supplier with Y 10.7.35 CVS46 §5.4.1 Vehicle test RI: External interference sources Y Engineering expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Engineering interpretation: Security view: Cybersecurity Evidence and DIA; Supplier Development and Production Hardening. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 47 Classification: Reclassified as Assumption Mandatory level: May Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00251 | P 1 Page 11 Functional safety The ECA is a part of a safety critical system and shall be handled as such.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: P 1 Page 11 Functional safety The ECA is a part of a safety critical system and shall be handled as such. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 49 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00252 | The ECA shall therefore be developed and implemented in accordance with the objectives and requirements of ISO 26262 "Road vehicles - Functional Safety".Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Compliance Process Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The ECA shall therefore be developed and implemented in accordance with the objectives and requirements of ISO 26262 "Road vehicles - Functional Safety". Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 49 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00253 | The supplier shall analyse risks of individua l HW and SW components, mechanics, and any other technologies, independently of the scope of ISO 26262.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Security Logging and Event Handling; Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: Compliance Process; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: The supplier shall analyse risks of individua l HW and SW components, mechanics, and any other technologies, independently of the scope of ISO 26262. Engineering expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Engineering interpretation: Security view: Security Logging and Event Handling; Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: Compliance Process; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: Compliance Process; OEM/Customer Review Interface Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 49 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00254 | For this purpose possible causes must be systematically identified.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: For this purpose possible causes must be systematically identified. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 49 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00255 | For these analyses at least the methods in ISO 26262 shall be applied.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Compliance Process Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: For these analyses at least the methods in ISO 26262 shall be applied. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 49 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00256 | ID Verification methods 12.1 Conformance to Requirement Specification A1 The supplier must do conformance test of all external and internal I/O.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA; Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: ID Verification methods 12.1 Conformance to Requirement Specification A1 The supplier must do conformance test of all external and internal I/O. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA; Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 50 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00257 | This test must verify that all internal and external I/O fulfils the requirements in this specification.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: This test must verify that all internal and external I/O fulfils the requirements in this specification. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 50 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00258 | A2 The supplier must perform full DV (Design Verification at B-sample level) and full PV (Product Validation at C-sample level) environmental test programs according to CVS40 and CVS41 (incl.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA; Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: A2 The supplier must perform full DV (Design Verification at B-sample level) and full PV (Product Validation at C-sample level) environmental test programs according to CVS40 and CVS41 (incl. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA; Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 50 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00259 | the suppler must carry out two full test rounds according to the Traton test requirements.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: the suppler must carry out two full test rounds according to the Traton test requirements. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 50 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00260 | Additional tests initiated and performed by the supplier must be discussed with Traton.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: Additional tests initiated and performed by the supplier must be discussed with Traton. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 50 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00261 | A3 The supplier must test the connectors according to TB1787.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: A3 The supplier must test the connectors according to TB1787. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 50 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00262 | A4 The supplier must do EMC tests with the unit alone.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: A4 The supplier must do EMC tests with the unit alone. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 50 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00263 | The supplier must certify the ECA according to UN ECE R10 (EMC), according to the latest revision with all amendments.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: The supplier must certify the ECA according to UN ECE R10 (EMC), according to the latest revision with all amendments. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 50 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00264 | A5 The supplier must check that both prototypes and serial units fulfil the dimension requirement according to any relevant Traton supplied drawings.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: A5 The supplier must check that both prototypes and serial units fulfil the dimension requirement according to any relevant Traton supplied drawings. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 50 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00265 | A6 All prototypes and serial ECA’s shall fulfil requirements according to TB1822, IPC/EIA J-STD-001 class 3 and IPC-A-610 class 3.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: A6 All prototypes and serial ECA’s shall fulfil requirements according to TB1822, IPC/EIA J-STD-001 class 3 and IPC-A-610 class 3. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 50 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00266 | 12.3 Testability The supplier of the unit must write software to enable his own testing of the unit during development, production and on any claimed unit.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: 12.3 Testability The supplier of the unit must write software to enable his own testing of the unit during development, production and on any claimed unit. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: Application Software; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: Application Software; OEM/Customer Review Interface Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 50 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00267 | However, dividing sample phases into several generations must be agreed upon between Traton and the supplier.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: However, dividing sample phases into several generations must be agreed upon between Traton and the supplier. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 51 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00268 | All samples shall be functionally tested before sent to Traton.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: All samples shall be functionally tested before sent to Traton. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 51 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00269 | Deviations shall be reported as a part of the sample delivery.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Deviations shall be reported as a part of the sample delivery. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 51 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00270 | Dimensional checks shall be performed for B and C-samples prior to delivery to Traton.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Dimensional checks shall be performed for B and C-samples prior to delivery to Traton. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 51 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00271 | The supplier must use the sample denominations requested by Traton.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: The supplier must use the sample denominations requested by Traton. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 51 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00272 | Unless otherwise stated, valid version is the latest available as of 1st May 2026.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | None | Interface: None Architecture: None Status: Missing security feature, interface, architecture | Medium Needed | DetailsFull requirement statement: Unless otherwise stated, valid version is the latest available as of 1st May 2026. Engineering expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Engineering interpretation: Traceability needs review before this requirement can be used as design evidence. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 52 Classification: Reclassified as Assumption Mandatory level: May Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00273 | P 1 Page Appendix B – Life length test The life time testing of the ECA shall consist of 6500000 repetitions of the test cycle described in ”I – Test cycle” Two different test profiles/setups can be used.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: P 1 Page Appendix B – Life length test The life time testing of the ECA shall consist of 6500000 repetitions of the test cycle described in ”I – Test cycle” Two different test profiles/setups can be used. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 57 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| req-5.1 | The full strokes should be performed within 180 ms, as specified in req 5.1 and 5.2.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Compliance Process; System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The full strokes should be performed within 180 ms, as specified in req 5.1 and 5.2. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Compliance Process; System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process; System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 57 Classification: Not Applicable Mandatory level: Should Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00275 | Between the two movements the actuator should remain in the fully disengaged position.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Between the two movements the actuator should remain in the fully disengaged position. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 57 Classification: Not Applicable Mandatory level: Should Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00276 | After the complete engagement the actuator should remain in this position until the next disengagement is requested.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: After the complete engagement the actuator should remain in this position until the next disengagement is requested. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 57 Classification: Not Applicable Mandatory level: Should Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00277 | • A function test rig shall be used for function tests between intervals • At 6.25M cycles a function test at -40C as well as the release frequency test is performed, before the rigs are put into run-to-failure mode • Run-to-failure mode implies cycling at intermediate load and RT/80C until failure • @Temp durability will start with 15/min frequency to verify if 30/min is feasible • One rig at RT shall run at 15/min as a reference unit for cycle acceleration.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: • A function test rig shall be used for function tests between intervals • At 6.25M cycles a function test at -40C as well as the release frequency test is performed, before the rigs are put into run-to-failure mode • Run-to-failure mode implies cycling at intermediate load and RT/80C until failure • @Temp durability will start with 15/min frequency to verify if 30/min is feasible • One rig at RT shall run at 15/min as a reference unit for cycle acceleration. Engineering expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 59 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00278 | This needs to be checked with the first test run and if necessary the test cycle used in profile B needs to be changed.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | None | Interface: None Architecture: None Status: Missing security feature, interface, architecture | Medium Needed | DetailsFull requirement statement: This needs to be checked with the first test run and if necessary the test cycle used in profile B needs to be changed. Engineering expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Engineering interpretation: Traceability needs review before this requirement can be used as design evidence. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: 3299216_1.pdf Source Markdown: converted/markdown-cleaned/3299216_1.md Page reference: page 61 Classification: Reclassified as Informational Mandatory level: Informational Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00279 | TRATON Software Update Variant 2 (SUV2) sequence Foreword This Commercial Vehicle Standard (“CVS123-2”) contains requirement specifications for TRATON Group and may be referred to by any of its commercial vehicle Affiliates.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Secure Software Update | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: TRATON Software Update Variant 2 (SUV2) sequence Foreword This Commercial Vehicle Standard (“CVS123-2”) contains requirement specifications for TRATON Group and may be referred to by any of its commercial vehicle Affiliates. Engineering expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Engineering interpretation: Security view: Secure Software Update. Mapped security capability: None Mapped feature: Secure software update and flash readiness Mapped interface: None Mapped architecture element: None Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 1 Classification: Reclassified as Assumption Mandatory level: May Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00280 | Any review of this CVS123-2 shall only be done in agreement with the involved TRATON Group commercial vehicle Affiliates stated in the table below under section “Technical responsibility”.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Compliance Process Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Any review of this CVS123-2 shall only be done in agreement with the involved TRATON Group commercial vehicle Affiliates stated in the table below under section “Technical responsibility”. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 1 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00281 | The User shall apply the latest version of this CVS123-2.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The User shall apply the latest version of this CVS123-2. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 1 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00282 | SUV2_INFO 7 The reason to why an ECU must implement two or more diagnostic servers is that it needs to support two or more different ECU configurations: one for which no application is installed and one or more for which applications are installed in the ECU.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA; Diagnostic security | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_INFO 7 The reason to why an ECU must implement two or more diagnostic servers is that it needs to support two or more different ECU configurations: one for which no application is installed and one or more for which applications are installed in the ECU. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA; Diagnostic security. Architecture view: Security Services. Mapped security capability: Diagnostic security Mapped feature: Diagnostic security Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 4 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00283 | SUV2_INFO 8 It should be noted that a single server view is not completely achievable and that clients still need to be aware of two physical servers.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: SUV2_INFO 8 It should be noted that a single server view is not completely achievable and that clients still need to be aware of two physical servers. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 4 Classification: Not Applicable Mandatory level: Should Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00284 | Clients may prefer to implement programming support using other service parameter values or even another set of programming steps thanExpectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Secure Software Update; Secure Communication and Boundary Control | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: Clients may prefer to implement programming support using other service parameter values or even another set of programming steps than Engineering expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Engineering interpretation: Security view: Secure Software Update; Secure Communication and Boundary Control. Mapped security capability: None Mapped feature: Secure software update and flash readiness Mapped interface: None Mapped architecture element: None Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 4 Classification: Reclassified as Assumption Mandatory level: May Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00285 | For this reason, only the server is required to support the specified sequence.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: For this reason, only the server is required to support the specified sequence. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 5 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00286 | Application data module (Calibration data) Contains a variant-specific set of parameter values that is required for correct operation of the control unit in a specific vehicle variant.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Application Software Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Application data module (Calibration data) Contains a variant-specific set of parameter values that is required for correct operation of the control unit in a specific vehicle variant. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 6 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00287 | It must be clearly separated from the application software.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Application Software Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: It must be clearly separated from the application software. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 6 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00288 | For this reason, it is located in a separate memory area and must also be erasable and programmable independently of the application software.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Application Software Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: For this reason, it is located in a separate memory area and must also be erasable and programmable independently of the application software. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 6 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00289 | Application software module Contains all vehicle functions required for the normal server operation.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Application Software Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Application software module Contains all vehicle functions required for the normal server operation. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 6 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00290 | All software parts required for the reprogramming like CAN driver, network layer, diagnostic services, boot operating system, start-up code, low level flash routines (for erasing, writing, reading), EEPROM access routines (read, write functionality), software compatibility checks etc.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Secure Boot and Application State Control; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: All software parts required for the reprogramming like CAN driver, network layer, diagnostic services, boot operating system, start-up code, low level flash routines (for erasing, writing, reading), EEPROM access routines (read, write functionality), software compatibility checks etc. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Secure Boot and Application State Control; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security. Architecture view: Security Services. Mapped security capability: Diagnostic security Mapped feature: Diagnostic security; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 6 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00291 | shall be implemented in the boot software code.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Boot and Application State Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: shall be implemented in the boot software code. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Boot and Application State Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 6 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00292 | The value of this variable (and C2, see below) may be used by the boot manager to determine whether to start the application or the boot loader.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Secure Boot and Application State Control | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: The value of this variable (and C2, see below) may be used by the boot manager to determine whether to start the application or the boot loader. Engineering expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Engineering interpretation: Security view: Secure Boot and Application State Control. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 6 Classification: Reclassified as Assumption Mandatory level: May Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ_UDS-0051 | More information on CVS124C2 Also referred to as “programming request” flag.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update | Interface: None Architecture: Application Software Status: Missing interface | Medium Needed | DetailsFull requirement statement: More information on CVS124 REQ_UDS 0051 C2 Also referred to as “programming request” flag. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; System behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 6 Classification: Reclassified as Informational Mandatory level: Informational Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00294 | The value of this variable (and C1, see above) may be used by the boot manager to determine whether or not to start the application or the boot loader.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Secure Boot and Application State Control | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: The value of this variable (and C1, see above) may be used by the boot manager to determine whether or not to start the application or the boot loader. Engineering expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Engineering interpretation: Security view: Secure Boot and Application State Control. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 6 Classification: Reclassified as Assumption Mandatory level: May Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ_UDS-0051 | More information on CVS124C3 Also referred to as “reprogrammed” flag.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Application Software Status: Missing interface | Medium Needed | DetailsFull requirement statement: More information on CVS124 REQ_UDS 0051 C3 Also referred to as “reprogrammed” flag. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; System behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 6 Classification: Reclassified as Informational Mandatory level: Informational Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00296 | The value of this variable may be used by the application to determine whether or not initialization is required.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Application Software Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The value of this variable may be used by the application to determine whether or not initialization is required. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 6 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00297 | Satisfied programming precondition A programming precondition agreed between supplier and vehicle manufacturer which, together with other agreed programming preconditions, shall be fulfilled before an ECU is made eligible for programming.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Software Update; Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: Hardware Platform; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: Satisfied programming precondition A programming precondition agreed between supplier and vehicle manufacturer which, together with other agreed programming preconditions, shall be fulfilled before an ECU is made eligible for programming. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Software Update; Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: Hardware Platform; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Hardware platform support; Secure software update and flash readiness Mapped interface: OEM/Customer Review Interface Mapped architecture element: Hardware Platform; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 7 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00298 | Tester System that controls functions such as test, inspection, monitoring, or diagnosis of an on-vehicle electronic control unit and may be dedicated to a specific type of operator (e.g., an off-board scan tool dedicated to garage mechanics, an off-board test tool dedicated to assembly plants, or an on-board tester) see (1) 3.2 Abbreviated terms Table 2: Abbreviated terms Abbreviation Description NRC Negative Response Code NR Negative Response APP Application software BLF Boot Loader Flash CDTCS Clear DTC Setting CF Consecutive Frame Def Default diagnostic session DIAG Changeable over diagnostics interface DID Data identifier DSC Data Security Container EMP Entity Management Protocol Ext Extended diagnostic session FF First Frame FLASH BOOT Boot loader module stored in flash memory FLASH DATA Data set module stored in flash memoryExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Secure Boot and Application State Control; Secure Communication and Boundary Control; Vulnerability and Incident Handling; Cybersecurity Evidence and DIA; Supplier Development and Production Hardening | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: Tester System that controls functions such as test, inspection, monitoring, or diagnosis of an on-vehicle electronic control unit and may be dedicated to a specific type of operator (e.g., an off-board scan tool dedicated to garage mechanics, an off-board test tool dedicated to assembly plants, or an on-board tester) see (1) 3.2 Abbreviated terms Table 2: Abbreviated terms Abbreviation Description NRC Negative Response Code NR Negative Response APP Application software BLF Boot Loader Flash CDTCS Clear DTC Setting CF Consecutive Frame Def Default diagnostic session DIAG Changeable over diagnostics interface DID Data identifier DSC Data Security Container EMP Entity Management Protocol Ext Extended diagnostic session FF First Frame FLASH BOOT Boot loader module stored in flash memory FLASH DATA Data set module stored in flash memory Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Secure Boot and Application State Control; Secure Communication and Boundary Control; Vulnerability and Incident Handling; Cybersecurity Evidence and DIA; Supplier Development and Production Hardening. Mapped security capability: None Mapped feature: Secure software update and flash readiness Mapped interface: None Mapped architecture element: None Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 7 Classification: Needs Manual Markdown Correction Mandatory level: May Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ-AUTO-00299 | Page 9 4 General requirements SUV2_REQ 1 The implementation of the client and the server shall be compliant with (ISO14229-1:2020) and the Traton Specification on Unified diagnostic Service (UDS) requirements (CVS124) with the clarifications, extensions and exceptions stated in this specification.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Page 9 4 General requirements SUV2_REQ 1 The implementation of the client and the server shall be compliant with (ISO14229-1:2020) and the Traton Specification on Unified diagnostic Service (UDS) requirements (CVS124) with the clarifications, extensions and exceptions stated in this specification. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security. Architecture view: Security Services. Mapped security capability: Diagnostic security Mapped feature: Diagnostic security Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00300 | Requirements in (CVS124) which are not explicitly stated to apply to the application only (such as communication parameters) shall apply to the boot loader as well.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Boot and Application State Control; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Requirements in (CVS124) which are not explicitly stated to apply to the application only (such as communication parameters) shall apply to the boot loader as well. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Boot and Application State Control; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00301 | SUV2_REQ 2 All deviations from this specification shall be agreed with the applicable vehicle manufacturer(s).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Missing security feature | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 2 All deviations from this specification shall be agreed with the applicable vehicle manufacturer(s). Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00302 | SUV2_REQ 3 The programming requirements in this specification shall apply to the programming of all kinds of software modules (application, application data and boot loader), unless explicitly otherwise stated.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Software Update; Secure Boot and Application State Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 3 The programming requirements in this specification shall apply to the programming of all kinds of software modules (application, application data and boot loader), unless explicitly otherwise stated. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Software Update; Secure Boot and Application State Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00303 | SUV2_REQ 4 If as a deviation with respect to SUV2_REQ 3 an ECU will not support boot loader reprogramming, the boot loader SW shall be in a protected area of the memory.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Software Update; Secure Boot and Application State Control | Interface: None Architecture: Hardware Platform Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 4 If as a deviation with respect to SUV2_REQ 3 an ECU will not support boot loader reprogramming, the boot loader SW shall be in a protected area of the memory. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Software Update; Secure Boot and Application State Control. Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00304 | A SW or HW protection mechanism shall be used to protect the software from being accidentally erased or overwritten.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Application Software Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: A SW or HW protection mechanism shall be used to protect the software from being accidentally erased or overwritten. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00305 | If the microcontroller supports HW protection, this shall be used.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: If the microcontroller supports HW protection, this shall be used. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00306 | SUV2_REQ 5 The server shall support programming of all application software and application data modules and any subset of such modules in a single sequence without any intermediate reset service requests.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Secure Software Update; Secure Boot and Application State Control; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 5 The server shall support programming of all application software and application data modules and any subset of such modules in a single sequence without any intermediate reset service requests. Engineering expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Engineering interpretation: Security view: Secure Software Update; Secure Boot and Application State Control; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00307 | SUV2_REQ 6 Programming of a subset of modules may lead to that the consistency check at the end of a programming sequence fails but shall not lead to that those programmed modules need to be reprogrammed from the beginning.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Software Update | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 6 Programming of a subset of modules may lead to that the consistency check at the end of a programming sequence fails but shall not lead to that those programmed modules need to be reprogrammed from the beginning. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Software Update. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: System Core Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00308 | SUV2_REQ 7 Boot loader updating according to this specification shall be supported during development, from A-samples and onwards.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Boot and Application State Control; Supplier Development and Production Hardening | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 7 Boot loader updating according to this specification shall be supported during development, from A-samples and onwards. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Boot and Application State Control; Supplier Development and Production Hardening. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00309 | SUV2_REQ 8 A server shall be programmable according to this specification (i.e., not only using supplier tools) regardless of whether one or more DTCs are currently active, or one or more functions are currently degraded.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 8 A server shall be programmable according to this specification (i.e., not only using supplier tools) regardless of whether one or more DTCs are currently active, or one or more functions are currently degraded. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: Backend and IT Systems; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: OEM/Customer Review Interface Mapped architecture element: Backend and IT Systems; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00310 | SUV2_REQ 9 A server shall be programmable while integrated in the vehicle network and as a standalone server without further conditions and without further interventions by the diagnostic tester as per this specification.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 9 A server shall be programmable while integrated in the vehicle network and as a standalone server without further conditions and without further interventions by the diagnostic tester as per this specification. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security. Architecture view: Security Services. Mapped security capability: Diagnostic security Mapped feature: Diagnostic security Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00311 | Page 10 SUV2_REQ 10 The solution for maintaining/reorganizing data (EEPROM data, operational data, adaptive data etc.) before and after reprogramming of software modules shall be discussed and agreed with the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Software Update | Interface: OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: Page 10 SUV2_REQ 10 The solution for maintaining/reorganizing data (EEPROM data, operational data, adaptive data etc.) before and after reprogramming of software modules shall be discussed and agreed with the vehicle manufacturer. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Software Update. Interface view: OEM/Customer Review Interface. Architecture view: Application Software; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Application software behavior; Secure software update and flash readiness Mapped interface: OEM/Customer Review Interface Mapped architecture element: Application Software; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00312 | 4.1 Documentation requirements SUV2_REQ 11 The supplier shall provide, for each committed software delivery, a document that describes the programming procedure together with any requirement exceptions and ECU specific behaviours.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Secure Software Update; Cybersecurity Evidence and DIA; Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: 4.1 Documentation requirements SUV2_REQ 11 The supplier shall provide, for each committed software delivery, a document that describes the programming procedure together with any requirement exceptions and ECU specific behaviours. Engineering expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Engineering interpretation: Security view: Secure Software Update; Cybersecurity Evidence and DIA; Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: Application Software; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Application software behavior; Secure software update and flash readiness; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: Application Software; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00313 | SUV2_REQ 12 Normal and worst-case performance values shall be documented for: • Total time for the programming sequence (programming steps prefixed “P1Pro”, see section Programming step of phase #1 – Download of application software and data).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Software Update | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 12 Normal and worst-case performance values shall be documented for: • Total time for the programming sequence (programming steps prefixed “P1Pro”, see section Programming step of phase #1 – Download of application software and data). Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Software Update. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00314 | SUV2_REQ 13 The supplier shall document the versioning concept for supplier specific DIDs.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 13 The supplier shall document the versioning concept for supplier specific DIDs. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00315 | 4.2 Software architecture requirements SUV2_REQ 14 System name (DID 0xF197), diagnostic address and bitrate shall be persisted in an application data module dedicated for boot parameters, referred to as “boot parameter module”.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control; Cybersecurity Evidence and DIA; Diagnostic security | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 4.2 Software architecture requirements SUV2_REQ 14 System name (DID 0xF197), diagnostic address and bitrate shall be persisted in an application data module dedicated for boot parameters, referred to as “boot parameter module”. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control; Cybersecurity Evidence and DIA; Diagnostic security. Architecture view: Security Services. Mapped security capability: Diagnostic security Mapped feature: Diagnostic security Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00316 | When this module is programmed the parameter values in it shall override default parameter values persisted in the boot loader software module.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Boot and Application State Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: When this module is programmed the parameter values in it shall override default parameter values persisted in the boot loader software module. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Boot and Application State Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00317 | It should be possible to reuse the generic bootloader for future currently unknown purposes/applications without a need to create a new part number for the platform.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Secure Software Update; Secure Boot and Application State Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Needed | DetailsFull requirement statement: It should be possible to reuse the generic bootloader for future currently unknown purposes/applications without a need to create a new part number for the platform. Engineering expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Engineering interpretation: Security view: Secure Software Update; Secure Boot and Application State Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 10 Classification: Not Applicable Mandatory level: Should Customer clarification status: Needed Human review status: Not needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00318 | SUV2_REQ 15 When the boot loader software in an ECU has not yet been parameterized (a boot parameter module has not been programmed) the boot loader software shall apply project specific default values, typically: • diagnostic address 0xA7 • baud rate 500 kb/s • DID 0xF197Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control; Cybersecurity Evidence and DIA; Diagnostic security | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 15 When the boot loader software in an ECU has not yet been parameterized (a boot parameter module has not been programmed) the boot loader software shall apply project specific default values, typically: • diagnostic address 0xA7 • baud rate 500 kb/s • DID 0xF197 Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control; Cybersecurity Evidence and DIA; Diagnostic security. Architecture view: Security Services. Mapped security capability: Diagnostic security Mapped feature: Diagnostic security Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00319 | SUV2_REQ 16 Default values for EOL parameters shall be implemented in a dedicated application data module, referred to as “EOL parameters module”.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Application Software Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 16 Default values for EOL parameters shall be implemented in a dedicated application data module, referred to as “EOL parameters module”. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00320 | SUV2_REQ 17 The partitioning of the ECU software into modules shall be discussed and agreed with the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface Status: Missing security feature | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 17 The partitioning of the ECU software into modules shall be discussed and agreed with the vehicle manufacturer. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Interface view: OEM/Customer Review Interface. Architecture view: Application Software; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: Application Software; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00321 | 4.3 Software distribution requirements SUV2_REQ 19 A software released for integration test, production or service market shall be hashed so its integrity can be verified by the server.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Supplier Development and Production Hardening | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 4.3 Software distribution requirements SUV2_REQ 19 A software released for integration test, production or service market shall be hashed so its integrity can be verified by the server. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Supplier Development and Production Hardening. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00322 | SUV2_REQ 20 Flash files delivered from the supplier shall never have to be modified by the vehicle manufacturer.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Secure Software Update; Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 20 Flash files delivered from the supplier shall never have to be modified by the vehicle manufacturer. Engineering expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Engineering interpretation: Security view: Secure Software Update; Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior; Secure software update and flash readiness Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00323 | SUV2_REQ 182 The supplier shall deliver the necessary information to verify the integrity of the flash files.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Secure Software Update; Data Authenticity and Integrity Verification; Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 182 The supplier shall deliver the necessary information to verify the integrity of the flash files. Engineering expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Engineering interpretation: Security view: Secure Software Update; Data Authenticity and Integrity Verification; Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior; Secure software update and flash readiness Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00324 | SUV2_INFO 129 In case the supplier delivers encrypted flash files to the vehicle manufacturer, the supplier should also provide the necessary information so the flash files can be verified as part of flash files update procedure.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Secure Software Update; Secure Communication and Boundary Control; Supplier Development and Production Hardening | Interface: External Interfaces; OEM/Customer Review Interface Architecture: External Interfaces; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: SUV2_INFO 129 In case the supplier delivers encrypted flash files to the vehicle manufacturer, the supplier should also provide the necessary information so the flash files can be verified as part of flash files update procedure. Engineering expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Engineering interpretation: Security view: Secure Software Update; Secure Communication and Boundary Control; Supplier Development and Production Hardening. Interface view: External Interfaces; OEM/Customer Review Interface. Architecture view: External Interfaces; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: External interfaces; Secure software update and flash readiness Mapped interface: External Interfaces; OEM/Customer Review Interface Mapped architecture element: External Interfaces; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 11 Classification: Not Applicable Mandatory level: Should Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00325 | SUV2_REQ 21 Whether or not the ECU shall be delivered from the supplier to the vehicle manufacturer with a pre-programmed application and pre-programmed application data shall be discussed and agreed with the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 21 Whether or not the ECU shall be delivered from the supplier to the vehicle manufacturer with a pre-programmed application and pre-programmed application data shall be discussed and agreed with the vehicle manufacturer. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: Application Software; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: Application Software; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00326 | SUV2_INFO 130 Regardless of if the ECU will be delivered from the supplier with a pre-programmed application and application data, the corresponding flash files shall be possible to request by vehicle manufacturer to be able to perform software verification at any time in vehicle manufacturer production site.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Secure Software Update; Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA; Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: SUV2_INFO 130 Regardless of if the ECU will be delivered from the supplier with a pre-programmed application and application data, the corresponding flash files shall be possible to request by vehicle manufacturer to be able to perform software verification at any time in vehicle manufacturer production site. Engineering expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Engineering interpretation: Security view: Secure Software Update; Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA; Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: Application Software; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Application software behavior; Secure software update and flash readiness; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: Application Software; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00327 | SUV2_REQ 22 When the application module is pre-programmed by the supplier, ECU and software identifiers 0xF187 and 0xF188 shall be set to product specific vehicle manufacturer defined values.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 22 When the application module is pre-programmed by the supplier, ECU and software identifiers 0xF187 and 0xF188 shall be set to product specific vehicle manufacturer defined values. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: Application Software; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: Application Software; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00328 | Otherwise 0xF187 and 0xF188 shall be set to default values, see CVS124.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Otherwise 0xF187 and 0xF188 shall be set to default values, see CVS124. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00329 | Page 12 5 Detailed programming sequence SUV2_REQ 23 Programmable servers shall support the full programming sequence described in this chapter.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Software Update | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Page 12 5 Detailed programming sequence SUV2_REQ 23 Programmable servers shall support the full programming sequence described in this chapter. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Software Update. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: System Core Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00330 | SUV2_REQ 24 Non-programmable servers shall support the pre-programming and post-programming steps of the programming sequence described in this chapter (phase 1 and 2).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Software Update | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 24 Non-programmable servers shall support the pre-programming and post-programming steps of the programming sequence described in this chapter (phase 1 and 2). Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Software Update. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: System Core Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00331 | SUV2_REQ 25 The programming sequence described in this chapter shall be supported when a valid application is present as well as when no valid application is present in the ECU.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Software Update; Secure Boot and Application State Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 25 The programming sequence described in this chapter shall be supported when a valid application is present as well as when no valid application is present in the ECU. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Software Update; Secure Boot and Application State Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00332 | The full set of addressing modes, SPRMIB values and other parameter values that the server shall support for each service are specified with implementation requirements in CVS124.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: The full set of addressing modes, SPRMIB values and other parameter values that the server shall support for each service are specified with implementation requirements in CVS124. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00333 | SUV2_REQ 26 To enable access to diagnostic services in the programming sequence, an authentication sequence shall be performed between the client and the server by means of the Authentication 0x29 service.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control; Key and Certificate Handling; Cybersecurity Evidence and DIA; Authentication | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 26 To enable access to diagnostic services in the programming sequence, an authentication sequence shall be performed between the client and the server by means of the Authentication 0x29 service. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control; Key and Certificate Handling; Cybersecurity Evidence and DIA; Authentication. Architecture view: Security Services. Mapped security capability: Authentication Mapped feature: Authentication; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00334 | SUV2_REQ 27 The server shall receive a diagnostic service authentication (0x29) with SubFunction deAuthenticate (0x00) message from the client to disable authorized access to diagnostic programming services after an update is considered fulfilled.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control; Key and Certificate Handling; Cybersecurity Evidence and DIA; Authentication | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 27 The server shall receive a diagnostic service authentication (0x29) with SubFunction deAuthenticate (0x00) message from the client to disable authorized access to diagnostic programming services after an update is considered fulfilled. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control; Key and Certificate Handling; Cybersecurity Evidence and DIA; Authentication. Architecture view: Security Services. Mapped security capability: Authentication Mapped feature: Authentication; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00335 | SUV2_INFO 35 As example, the client may read certificate validity time and/or RBAC configuration file to verify if the appropriate entities are stored in the server.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Secure Diagnostics and RBAC; Data Authenticity and Integrity Verification; Key and Certificate Handling | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: SUV2_INFO 35 As example, the client may read certificate validity time and/or RBAC configuration file to verify if the appropriate entities are stored in the server. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Data Authenticity and Integrity Verification; Key and Certificate Handling. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 14 Classification: Reclassified as Assumption Mandatory level: May Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00336 | SUV2_INFO 39 As example, the client may have identified that the RBAC configuration file requires update and perform the appropriate set to update the entities stored in the server.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Secure Diagnostics and RBAC; Secure Software Update | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_INFO 39 As example, the client may have identified that the RBAC configuration file requires update and perform the appropriate set to update the entities stored in the server. Engineering expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 14 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00337 | Alternatively, it may be a client strategy to always update certain entities prior to a software update.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Secure Software Update | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: Alternatively, it may be a client strategy to always update certain entities prior to a software update. Engineering expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Engineering interpretation: Security view: Secure Software Update. Mapped security capability: None Mapped feature: Secure software update and flash readiness Mapped interface: None Mapped architecture element: None Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 14 Classification: Reclassified as Assumption Mandatory level: May Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00338 | SUV2_INFO 52 Since Link Control is only applicable in production when no application has been programmed by the supplier, the application may return NRC 0x7F (serviceNotSupportedInActiveSession) to this service request and expect the client to proceed to the next step.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface Status: Complete | Medium Needed | DetailsFull requirement statement: SUV2_INFO 52 Since Link Control is only applicable in production when no application has been programmed by the supplier, the application may return NRC 0x7F (serviceNotSupportedInActiveSession) to this service request and expect the client to proceed to the next step. Engineering expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: Application Software; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: Application Software; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 15 Classification: Reclassified as Constraint Mandatory level: May Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00339 | SUV2_REQ 28 For the server to verify the integrity of the software, the information to verify shall be available to the server before step P1Pro6: Routine Control (erase Memory).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 28 For the server to verify the integrity of the software, the information to verify shall be available to the server before step P1Pro6: Routine Control (erase Memory). Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 16 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00340 | SUV2_REQ 29 If the SW to be updated is encrypted, decryption keys shall be available to the server before step P1Pro9.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Secure Software Update; Key and Certificate Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 29 If the SW to be updated is encrypted, decryption keys shall be available to the server before step P1Pro9. Engineering expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Engineering interpretation: Security view: Secure Software Update; Key and Certificate Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 16 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00341 | SUV2_REQ 30 Before the server executes the TransferData service, the server shall check if the data received during RequestDownload requests needs to be decrypted before writing the received data to non-volatile memory.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Software Update; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 30 Before the server executes the TransferData service, the server shall check if the data received during RequestDownload requests needs to be decrypted before writing the received data to non-volatile memory. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Software Update; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 16 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0051 | SUV2_INFO 66 Implementation hint: The server resets the “application valid” flag (C1, see CVS124) before the erase process starts, to ensure that the server will start in boot loader mode if the programming gets interrupted or if the programming is faulty.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Secure Boot and Application State Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Needed | DetailsFull requirement statement: SUV2_INFO 66 Implementation hint: The server resets the “application valid” flag (C1, see CVS124 REQ_UDS 0051) before the erase process starts, to ensure that the server will start in boot loader mode if the programming gets interrupted or if the programming is faulty. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Secure Boot and Application State Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; System behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 17 Classification: Reclassified as Informational Mandatory level: Informational Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00343 | SUV2_INFO 82 Implementation hint: The integrity information may contain parts of memory not programmed, regardless of this the server verifies the integrity according to the supplied information on SDSC, see 9.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Data Authenticity and Integrity Verification | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: SUV2_INFO 82 Implementation hint: The integrity information may contain parts of memory not programmed, regardless of this the server verifies the integrity according to the supplied information on SDSC, see 9. Engineering expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Engineering interpretation: Security view: Data Authenticity and Integrity Verification. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 19 Classification: Reclassified as Assumption Mandatory level: May Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00344 | SUV2_INFO 93 If the application was started, it checks if application initialization is required.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Application Software Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: SUV2_INFO 93 If the application was started, it checks if application initialization is required. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 20 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00345 | If so, the server performs the required checks/reorganization measures for the data structures (EEPROM data, operational data, adaptive data etc.), executes the self-test and stores event memory entries, default values, DIDs F1AB, F1AA, F1A9 etc.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Security Logging and Event Handling | Interface: None Architecture: Hardware Platform Status: Missing interface | Medium Not needed | DetailsFull requirement statement: If so, the server performs the required checks/reorganization measures for the data structures (EEPROM data, operational data, adaptive data etc.), executes the self-test and stores event memory entries, default values, DIDs F1AB, F1AA, F1A9 etc. Engineering expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Engineering interpretation: Security view: Security Logging and Event Handling. Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 20 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00346 | SUV2_INFO 94 Implementation hint: The ECU application checks the reprogrammed flag (C3, see programming step P1Pro11) to see if application initialization is required.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Software Update | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_INFO 94 Implementation hint: The ECU application checks the reprogrammed flag (C3, see programming step P1Pro11) to see if application initialization is required. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Software Update. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 20 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00347 | SUV2_INFO 85 As example, the client may have identified that the new software requires an updated RBAC configuration file and therefore set the entity on the server via EMP.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Secure Diagnostics and RBAC; Secure Software Update | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_INFO 85 As example, the client may have identified that the new software requires an updated RBAC configuration file and therefore set the entity on the server via EMP. Engineering expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 20 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00348 | Page 21 6 Server reprogramming requirements 6.1 Requirements for servers to support programming SUV2_REQ 33 ECUs that will be programmed stand-alone at the vehicle manufacturer over DoCAN shall support 1 Mbit transfer speed.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Software Update; Secure Communication and Boundary Control | Interface: OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: Page 21 6 Server reprogramming requirements 6.1 Requirements for servers to support programming SUV2_REQ 33 ECUs that will be programmed stand-alone at the vehicle manufacturer over DoCAN shall support 1 Mbit transfer speed. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Software Update; Secure Communication and Boundary Control. Interface view: OEM/Customer Review Interface. Architecture view: Backend and IT Systems; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Backend and IT integration; Secure software update and flash readiness Mapped interface: OEM/Customer Review Interface Mapped architecture element: Backend and IT Systems; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 21 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00349 | SUV2_REQ 34 Whether or not the ECU shall support stand-alone programming at the vehicle manufacturer premises shall be discussed and agreed with the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Software Update | Interface: OEM/Customer Review Interface Architecture: Hardware Platform; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 34 Whether or not the ECU shall support stand-alone programming at the vehicle manufacturer premises shall be discussed and agreed with the vehicle manufacturer. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Software Update. Interface view: OEM/Customer Review Interface. Architecture view: Hardware Platform; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Hardware platform support; Secure software update and flash readiness Mapped interface: OEM/Customer Review Interface Mapped architecture element: Hardware Platform; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 21 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00350 | SUV2_REQ 35 A server that is running in the application shall respond with the same diagnostic address after a switch to boot.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control; Cybersecurity Evidence and DIA; Diagnostic security | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 35 A server that is running in the application shall respond with the same diagnostic address after a switch to boot. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control; Cybersecurity Evidence and DIA; Diagnostic security. Architecture view: Security Services. Mapped security capability: Diagnostic security Mapped feature: Diagnostic security Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 21 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00351 | SUV2_REQ 36 It shall be possible to downgrade server software modules as long as the programmed modules are compatible with each other and with the hardware configuration.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Application Software Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 36 It shall be possible to downgrade server software modules as long as the programmed modules are compatible with each other and with the hardware configuration. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 21 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00352 | SUV2_REQ 37 Application software and application data modules shall be programmable in any order.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Application Software Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 37 Application software and application data modules shall be programmable in any order. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 21 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00353 | SUV2_REQ 38 The server shall be able to update an individual module independently from any other module.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Secure Software Update | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 38 The server shall be able to update an individual module independently from any other module. Engineering expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Engineering interpretation: Security view: Secure Software Update. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 21 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00354 | SUV2_REQ 39 If the performance requirements SUV2_REQ 62 or SUV2_REQ 63 cannot be met, a compression method shall be implemented.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 39 If the performance requirements SUV2_REQ 62 or SUV2_REQ 63 cannot be met, a compression method shall be implemented. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 21 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00355 | SUV2_REQ 40 The LZSS algorithm with a dictionary size of 1 023 bytes or a newer compression/decompression method with a higher compression ratio shall be used as the compression/decompression algorithm.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 40 The LZSS algorithm with a dictionary size of 1 023 bytes or a newer compression/decompression method with a higher compression ratio shall be used as the compression/decompression algorithm. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 21 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00356 | SUV2_REQ 41 The use of alternative compression/decompression algorithms shall be agreed with the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Missing security feature | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 41 The use of alternative compression/decompression algorithms shall be agreed with the vehicle manufacturer. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 21 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00357 | SUV2_REQ 42 It shall be possible to program the same software version repeatedly.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Application Software Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 42 It shall be possible to program the same software version repeatedly. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 21 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00358 | SUV2_REQ 43 If at startup the ECU hardware/software is consistent and a programming request is not pending, the boot manager shall start and execute the application.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Software Update; Secure Boot and Application State Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 43 If at startup the ECU hardware/software is consistent and a programming request is not pending, the boot manager shall start and execute the application. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Software Update; Secure Boot and Application State Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 21 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00359 | SUV2_REQ 44 Otherwise if at startup the ECU hardware/software is inconsistent the boot manager shall start and execute the boot loader and reset DIDs 0xF181, 0xF187 and 0xF188 and 0xF1A1 to default values.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Boot and Application State Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 44 Otherwise if at startup the ECU hardware/software is inconsistent the boot manager shall start and execute the boot loader and reset DIDs 0xF181, 0xF187 and 0xF188 and 0xF1A1 to default values. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Boot and Application State Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 21 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00360 | SUV2_REQ 45 If at startup the boot manager starts and executes the application, the application shall read and apply the parameter values persisted in the boot parameter module.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Boot and Application State Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 45 If at startup the boot manager starts and executes the application, the application shall read and apply the parameter values persisted in the boot parameter module. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Boot and Application State Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 21 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00361 | Otherwise if at startup the boot manager starts and executes the boot loader and a valid boot parameter module has been successfully programmed, the boot loader shall read and apply these parameter values from the boot parameter module.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Boot and Application State Control | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Otherwise if at startup the boot manager starts and executes the boot loader and a valid boot parameter module has been successfully programmed, the boot loader shall read and apply these parameter values from the boot parameter module. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Boot and Application State Control. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 21 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00362 | Otherwise if no boot parameter module has been successfully programmed, the boot loader shall apply the corresponding parameter values persisted in the boot loader module.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Boot and Application State Control | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Otherwise if no boot parameter module has been successfully programmed, the boot loader shall apply the corresponding parameter values persisted in the boot loader module. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Boot and Application State Control. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 21 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00363 | Page 22 SUV2_REQ 46 After reprogramming, the application shall store DIDs F1AB, F1AA, F1A9.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Software Update | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Page 22 SUV2_REQ 46 After reprogramming, the application shall store DIDs F1AB, F1AA, F1A9. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Software Update. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 22 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00364 | SUV2_REQ 47 The technical implementation of the programming preconditions shall be agreed between the supplier and the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Software Update; Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 47 The technical implementation of the programming preconditions shall be agreed between the supplier and the vehicle manufacturer. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Software Update; Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior; Secure software update and flash readiness Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 22 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00365 | SUV2_REQ 48 A programmable server shall guarantee re-programmability within the normal operating voltage range specified by [11] for 24V systems or [12] for 12V systems.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 48 A programmable server shall guarantee re-programmability within the normal operating voltage range specified by [11] for 24V systems or [12] for 12V systems. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 22 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00366 | SUV2_REQ 49 A server that is restarted for any reason or thrown back to DefaultSession due to lack of TesterPresent or unfulfilled preconditions shall always support programming from the start of the programming sequence (programming step P1Pre), i.e., shall not depend on any state from an interrupted programming sequence.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC; Secure Software Update | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 49 A server that is restarted for any reason or thrown back to DefaultSession due to lack of TesterPresent or unfulfilled preconditions shall always support programming from the start of the programming sequence (programming step P1Pre), i.e., shall not depend on any state from an interrupted programming sequence. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 22 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00367 | 6.1.1 Boot software description and requirements 6.1.1.1 Boot software general requirements SUV2_REQ 50 The server shall guarantee re-programmability in the event of error conditions during the programming process regardless of cause.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Secure Software Update; Secure Boot and Application State Control; Security Logging and Event Handling | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 6.1.1 Boot software description and requirements 6.1.1.1 Boot software general requirements SUV2_REQ 50 The server shall guarantee re-programmability in the event of error conditions during the programming process regardless of cause. Engineering expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Engineering interpretation: Security view: Secure Software Update; Secure Boot and Application State Control; Security Logging and Event Handling. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 22 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00368 | The causes specified in (ISO14229-1:2020) shall be regarded as examples.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The causes specified in (ISO14229-1:2020) shall be regarded as examples. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 22 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00369 | SUV2_REQ 51 The server shall be re-programmable (standalone and in the vehicle) regardless of whether the application and application data is valid or has been corrupted.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Application Software Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 51 The server shall be re-programmable (standalone and in the vehicle) regardless of whether the application and application data is valid or has been corrupted. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 22 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00370 | 6.1.1.2 Boot software session requirements SUV2_REQ 52 Diagnostic services support shall be as per CVS124.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 6.1.1.2 Boot software session requirements SUV2_REQ 52 Diagnostic services support shall be as per CVS124. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security. Architecture view: Security Services. Mapped security capability: Diagnostic security Mapped feature: Diagnostic security Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 22 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00371 | SUV2_REQ 53 Additionally, the services specified in Table 3 shall be supported.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 53 Additionally, the services specified in Table 3 shall be supported. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 22 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00372 | Non-Def = Any other session than default diagnostic session 6.1.1.3 ECU Identification Data SUV2_REQ 55 ECU identification data support shall be as per CVS124.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA; Diagnostic security | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Non-Def = Any other session than default diagnostic session 6.1.1.3 ECU Identification Data SUV2_REQ 55 ECU identification data support shall be as per CVS124. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA; Diagnostic security. Architecture view: Security Services. Mapped security capability: Diagnostic security Mapped feature: Diagnostic security Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 23 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00373 | 6.1.1.4 Performance requirements SUV2_REQ 62 When programmed in the vehicle manufacturer’s production facility the total time for programming of all modules shall not exceed 90 seconds with the programming sequence described in chapter Programming phase #1 – Download of application software and/or application data (phase #1 and phase #2).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Software Update; Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: 6.1.1.4 Performance requirements SUV2_REQ 62 When programmed in the vehicle manufacturer’s production facility the total time for programming of all modules shall not exceed 90 seconds with the programming sequence described in chapter Programming phase #1 – Download of application software and/or application data (phase #1 and phase #2). Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Software Update; Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: Application Software; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Application software behavior; Secure software update and flash readiness Mapped interface: OEM/Customer Review Interface Mapped architecture element: Application Software; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 23 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00374 | SUV2_INFO 106 This does not apply to ECUs for which all software modules are pre-programmed in supplier premises, even if a software update capability is required in vehicle manufacturer production premises, e.g., for bug fixing.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Secure Software Update; Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: SUV2_INFO 106 This does not apply to ECUs for which all software modules are pre-programmed in supplier premises, even if a software update capability is required in vehicle manufacturer production premises, e.g., for bug fixing. Engineering expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Engineering interpretation: Security view: Secure Software Update; Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: Application Software; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Application software behavior; Secure software update and flash readiness Mapped interface: OEM/Customer Review Interface Mapped architecture element: Application Software; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 23 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00375 | SUV2_REQ 63 When programmed in the workshop the total time for programming of all modules shall not exceed 10 minutes with the programming sequence described in chapter Programming phase #1 – Download of application software and/or application data (phase #1 and phase #2).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Software Update | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 63 When programmed in the workshop the total time for programming of all modules shall not exceed 10 minutes with the programming sequence described in chapter Programming phase #1 – Download of application software and/or application data (phase #1 and phase #2). Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Software Update. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 23 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00376 | 6.1.1.4.1 Server routine access SUV2_REQ 64 The server shall support the routines specified in Table 4.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 6.1.1.4.1 Server routine access SUV2_REQ 64 The server shall support the routines specified in Table 4. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 23 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00377 | 7 Diagnostic service requirements 7.1 RequestDownload (0x34) Service SUV2_REQ 65 If the most recent Erase Memory routine request in the current session was made with the addressAndLengthFormatIdentifier parameter set to value 0x00 the server shall start erasing the memory area specified with the RequestDownload request.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 7 Diagnostic service requirements 7.1 RequestDownload (0x34) Service SUV2_REQ 65 If the most recent Erase Memory routine request in the current session was made with the addressAndLengthFormatIdentifier parameter set to value 0x00 the server shall start erasing the memory area specified with the RequestDownload request. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security. Architecture view: Security Services. Mapped security capability: Diagnostic security Mapped feature: Diagnostic security Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 24 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00378 | SUV2_INFO 107 In order to satisfy stability requirements, the erasing of the boot loader may require that the old boot loader is copied into another memory area before the boot loader memory is erased, see Annex A for an implementation hint.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Secure Boot and Application State Control | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: SUV2_INFO 107 In order to satisfy stability requirements, the erasing of the boot loader may require that the old boot loader is copied into another memory area before the boot loader memory is erased, see Annex A for an implementation hint. Engineering expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Engineering interpretation: Security view: Secure Boot and Application State Control. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 24 Classification: Reclassified as Assumption Mandatory level: May Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00379 | SUV2_REQ 66 If the most recent Erase Memory routine request in the current session was made with the addressAndLengthFormatIdentifier parameter set to value 0x00 the server shall reset the following identification DIDs to their default values: • If boot software download is requested, reset 0xF180, 0xF191 and 0xF187 to default values (some of the DIDs will be automatically erased as a consequence of erasing one or more modules).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC; Secure Boot and Application State Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 66 If the most recent Erase Memory routine request in the current session was made with the addressAndLengthFormatIdentifier parameter set to value 0x00 the server shall reset the following identification DIDs to their default values: • If boot software download is requested, reset 0xF180, 0xF191 and 0xF187 to default values (some of the DIDs will be automatically erased as a consequence of erasing one or more modules). Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 24 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00380 | SUV2_REQ 67 Once the RequestDownload service has started, only services TesterPresent, ECUReset,TransferData and DiagnosticSessionControl shall be permitted until service RequestTransferExit has been called or until any of these services returns an error.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Secure Boot and Application State Control; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 67 Once the RequestDownload service has started, only services TesterPresent, ECUReset,TransferData and DiagnosticSessionControl shall be permitted until service RequestTransferExit has been called or until any of these services returns an error. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Secure Boot and Application State Control; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 24 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00381 | SUV2_REQ 68 If a non-permitted service is requested after the RequestDownload service has started and before RequestTransferExit has been called the server shall respond with NRC 0x24Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Software Update; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 68 If a non-permitted service is requested after the RequestDownload service has started and before RequestTransferExit has been called the server shall respond with NRC 0x24 Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Software Update; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 24 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00382 | Page 25 (requestSequenceError) and shall accept programming to proceed from the state at which it was executing before this non-permitted service was requested.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Software Update; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Page 25 (requestSequenceError) and shall accept programming to proceed from the state at which it was executing before this non-permitted service was requested. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Software Update; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 25 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00383 | SUV2_REQ 69 For each received RequestDownload request, the server shall check if there is a VerificationEntry match in SDSC.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Software Update; Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA | Interface: OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 69 For each received RequestDownload request, the server shall check if there is a VerificationEntry match in SDSC. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Software Update; Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA. Interface view: OEM/Customer Review Interface. Architecture view: Backend and IT Systems; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Backend and IT integration; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: Backend and IT Systems; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 25 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00384 | SUV2_REQ 71 The server shall check whether any part of the received data is encrypted or not by checking the address ranges for a match in EncryptionEntry defined in SDSC.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 71 The server shall check whether any part of the received data is encrypted or not by checking the address ranges for a match in EncryptionEntry defined in SDSC. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 25 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00385 | SUV2_REQ 190 The server shall not execute the new software until it can be verified using routine 0xFF01.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 190 The server shall not execute the new software until it can be verified using routine 0xFF01. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 25 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00386 | 7.1.1 Request SUV2_REQ 72 The server shall support service request formatted according to Table 5.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 7.1.1 Request SUV2_REQ 72 The server shall support service request formatted according to Table 5. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 25 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00387 | Page 26 7.1.2 Positive Response SUV2_REQ 73 The server shall support service positive response formatted according to Table 6.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Page 26 7.1.2 Positive Response SUV2_REQ 73 The server shall support service positive response formatted according to Table 6. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 26 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00388 | #4 maxNumberOfBlockLength[] = [ byte #1 (MSB) byte #2 ] M 0x0000 – 0xFFFF 7.1.3 Negative Response SUV2_REQ 74 The server shall support service negative response as per ISO14229-1:2020.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: #4 maxNumberOfBlockLength[] = [ byte #1 (MSB) byte #2 ] M 0x0000 – 0xFFFF 7.1.3 Negative Response SUV2_REQ 74 The server shall support service negative response as per ISO14229-1:2020. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 26 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00389 | 7.1.4 Service 0x34 Parameters SUV2_REQ 165 In case a software is encrypted, the server shall decrypt the software before decompression and software hash comparison verification are performed.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA | Interface: OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: 7.1.4 Service 0x34 Parameters SUV2_REQ 165 In case a software is encrypted, the server shall decrypt the software before decompression and software hash comparison verification are performed. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA. Interface view: OEM/Customer Review Interface. Architecture view: Application Software; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Application software behavior; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: Application Software; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 26 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00390 | SUV2_REQ 166 In case a software is compressed, the server shall decompress the software before software hash comparison verification is performed.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA | Interface: OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 166 In case a software is compressed, the server shall decompress the software before software hash comparison verification is performed. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA. Interface view: OEM/Customer Review Interface. Architecture view: Application Software; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Application software behavior; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: Application Software; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 26 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00391 | SUV2_REQ 167 The server shall verify the software hash after decryption and/or decompression are performed.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 167 The server shall verify the software hash after decryption and/or decompression are performed. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 26 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00392 | 7.1.4.1 Parameter dataFormatIdentifier SUV2_REQ 75 The server shall support parameter dataFormatIdentifier formatted according to Table 7.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 7.1.4.1 Parameter dataFormatIdentifier SUV2_REQ 75 The server shall support parameter dataFormatIdentifier formatted according to Table 7. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 26 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00393 | Page 27 7.1.4.2 Parameter addressAndLengthFormatIdentifier SUV2_REQ 76 The server shall support parameter addressAndLengthFormatIdentifier formatted according to Table 8.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Page 27 7.1.4.2 Parameter addressAndLengthFormatIdentifier SUV2_REQ 76 The server shall support parameter addressAndLengthFormatIdentifier formatted according to Table 8. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 27 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00394 | Table 8: Service 0x34 addressAndLengthFormatIdentifier Format Bits Description Cvt Values 74 Length (number of bytes) of the memorySize parameter M 3,4 3 - 0 Length (number of bytes) of the memoryAddress parameter M 3, 4 7.1.4.3 Parameter lengthFormatIdentifier SUV2_REQ 77 The server shall support parameter lengthFormatIdentifier formatted according to Table 9.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Table 8: Service 0x34 addressAndLengthFormatIdentifier Format Bits Description Cvt Values 7 - 4 Length (number of bytes) of the memorySize parameter M 3,4 3 - 0 Length (number of bytes) of the memoryAddress parameter M 3, 4 7.1.4.3 Parameter lengthFormatIdentifier SUV2_REQ 77 The server shall support parameter lengthFormatIdentifier formatted according to Table 9. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 27 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00395 | M 0 7.2 TransferData (0x36) Service 7.2.1 Request SUV2_REQ 78 The server shall support request formatted according to ISO14229-1:2020.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Software Update; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: M 0 7.2 TransferData (0x36) Service 7.2.1 Request SUV2_REQ 78 The server shall support request formatted according to ISO14229-1:2020. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Software Update; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 27 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00396 | 7.2.2 Positive Response SUV2_REQ 79 The server shall support positive response formatted according to ISO14229-1:2020.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 7.2.2 Positive Response SUV2_REQ 79 The server shall support positive response formatted according to ISO14229-1:2020. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 27 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00397 | 7.2.3 Negative Response SUV2_REQ 80 SUV2_REQ 81 If for any reason an error occurs during decryption of data, the server shall return NRC 0x10.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 7.2.3 Negative Response SUV2_REQ 80 SUV2_REQ 81 If for any reason an error occurs during decryption of data, the server shall return NRC 0x10. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 27 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00398 | 7.2.4 Service 0x36 Parameters 7.2.4.1 Parameter blockSequenceCounter SUV2_REQ 82 The server shall support parameter blockSequenceCounter formatted according to ISO14229-1:2020.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 7.2.4 Service 0x36 Parameters 7.2.4.1 Parameter blockSequenceCounter SUV2_REQ 82 The server shall support parameter blockSequenceCounter formatted according to ISO14229-1:2020. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 27 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00399 | Page 28 7.2.4.2 Parameter transferRequestParameterRecord SUV2_REQ 83 The server shall support parameter transferRequestParameterRecord formatted according to ISO14229-1:2020.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Page 28 7.2.4.2 Parameter transferRequestParameterRecord SUV2_REQ 83 The server shall support parameter transferRequestParameterRecord formatted according to ISO14229-1:2020. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 28 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00400 | 7.3 RequestTransferExit (0x37) Service 7.3.1 Request SUV2_REQ 84 The server shall support request formatted according to Table 10.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 7.3 RequestTransferExit (0x37) Service 7.3.1 Request SUV2_REQ 84 The server shall support request formatted according to Table 10. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 28 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00401 | Table 10: Service 0x37 Request Format Byte No Description Cvt Byte Value 1 RequestTransferExit Request SID M 0x37 7.3.2 Positive Response SUV2_REQ 85 The server shall support positive response formatted according to Table 11.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Table 10: Service 0x37 Request Format Byte No Description Cvt Byte Value 1 RequestTransferExit Request SID M 0x37 7.3.2 Positive Response SUV2_REQ 85 The server shall support positive response formatted according to Table 11. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 28 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00402 | Table 11: Service 0x37 Positive Response Format Byte No Description Cvt Byte Value 1 RequestTransferExit Response SID M 0x77 7.3.3 Negative Response SUV2_REQ 86 7.3.4 Service 0x37 Parameters 7.3.4.1 Parameter transferRequestParameterRecord SUV2_REQ 87 The server shall not support transferRequestParameterRecord parameter.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Table 11: Service 0x37 Positive Response Format Byte No Description Cvt Byte Value 1 RequestTransferExit Response SID M 0x77 7.3.3 Negative Response SUV2_REQ 86 7.3.4 Service 0x37 Parameters 7.3.4.1 Parameter transferRequestParameterRecord SUV2_REQ 87 The server shall not support transferRequestParameterRecord parameter. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 28 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00403 | 7.3.4.2 Parameter transferResponseParameterRecord SUV2_REQ 88 The server shall not support transferResponseParameterRecord parameter.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 7.3.4.2 Parameter transferResponseParameterRecord SUV2_REQ 88 The server shall not support transferResponseParameterRecord parameter. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 28 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00404 | 7.4 SecuredDataTranmission (0x84) Service SUV2_REQ 89 The server shall support service 0x84 according to CVS32.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 7.4 SecuredDataTranmission (0x84) Service SUV2_REQ 89 The server shall support service 0x84 according to CVS32. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 28 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00405 | 7.4.1 Request SUV2_REQ 90 The server shall support request formatted according to ISO14229-1:2020.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 7.4.1 Request SUV2_REQ 90 The server shall support request formatted according to ISO14229-1:2020. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 28 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00406 | Page 29 7.4.2 Positive Response SUV2_REQ 91 The server shall support positive response formatted according to ISO14229-1:2020.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Page 29 7.4.2 Positive Response SUV2_REQ 91 The server shall support positive response formatted according to ISO14229-1:2020. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 29 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00407 | 7.4.3 Negative Response SUV2_REQ 92 SUV2_REQ 93 The server shall support negative response codes according to CVS32.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 7.4.3 Negative Response SUV2_REQ 92 SUV2_REQ 93 The server shall support negative response codes according to CVS32. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 29 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00408 | 7.4.4 Service 0x84 Parameters 7.4.4.1 Parameter Administrative Parameter SUV2_REQ 94 The server shall support parameter Administrative Parameter formatted according to ISO14229-1:2020.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 7.4.4 Service 0x84 Parameters 7.4.4.1 Parameter Administrative Parameter SUV2_REQ 94 The server shall support parameter Administrative Parameter formatted according to ISO14229-1:2020. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 29 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00409 | 7.4.4.2 Parameter Signature/Encryption Calculation (SIGENCRYPT) SUV2_REQ 95 The server shall support parameter Signature/Encryption Calculation (SIGENCRYPT) according to CVS32.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 7.4.4.2 Parameter Signature/Encryption Calculation (SIGENCRYPT) SUV2_REQ 95 The server shall support parameter Signature/Encryption Calculation (SIGENCRYPT) according to CVS32. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 29 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00410 | 7.4.4.3 Parameter Anti-replay Counter (ANTIREPLAYCNT) SUV2_REQ 96 The server shall support parameter Anti-replay Counter (ANTIREPLAYCNT) according to CVS32.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 7.4.4.3 Parameter Anti-replay Counter (ANTIREPLAYCNT) SUV2_REQ 96 The server shall support parameter Anti-replay Counter (ANTIREPLAYCNT) according to CVS32. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Secure communication and freshness protection; Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 29 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00411 | 8 Diagnostic Routine Identifier Requirements 8.1 Routine Session and routineControlSupport 8.1.1 Routine Session Support SUV2_REQ 97 The server shall support the routine in the diagnosticSession according to Table 12.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA; Diagnostic security | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 8 Diagnostic Routine Identifier Requirements 8.1 Routine Session and routineControlSupport 8.1.1 Routine Session Support SUV2_REQ 97 The server shall support the routine in the diagnosticSession according to Table 12. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA; Diagnostic security. Architecture view: Security Services. Mapped security capability: Diagnostic security Mapped feature: Diagnostic security Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 29 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00412 | Non-Def = Any other session than default diagnostic session 8.1.2 Routine routineControlType Support SUV2_REQ 98 The server shall support the routineControlType according to Table 13.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA; Diagnostic security | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Non-Def = Any other session than default diagnostic session 8.1.2 Routine routineControlType Support SUV2_REQ 98 The server shall support the routineControlType according to Table 13. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA; Diagnostic security. Architecture view: Security Services. Mapped security capability: Diagnostic security Mapped feature: Diagnostic security Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 30 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00413 | Table 13: Routine Support per routineControlType RID Name routineControlType startRoutine (0x01) stopRoutine (0x02) requestRoutineResults (0x03) 0x2202 Check Memory Block M - - 0xFF00 EraseMemory M - - 0xFF01 CheckProgrammingDependencies M - - 0xCAFE Entity Management Protocol (EMP) M - - M = Mandatory 8.1.3 Routine Safe State Requirement SUV2_REQ 181 The server shall implement diagnostic safe state, as per CVS124, as preconditions to the routines according to Table 14.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Cybersecurity Evidence and DIA; Diagnostic security | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Table 13: Routine Support per routineControlType RID Name routineControlType startRoutine (0x01) stopRoutine (0x02) requestRoutineResults (0x03) 0x2202 Check Memory Block M - - 0xFF00 EraseMemory M - - 0xFF01 CheckProgrammingDependencies M - - 0xCAFE Entity Management Protocol (EMP) M - - M = Mandatory 8.1.3 Routine Safe State Requirement SUV2_REQ 181 The server shall implement diagnostic safe state, as per CVS124, as preconditions to the routines according to Table 14. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Cybersecurity Evidence and DIA; Diagnostic security. Architecture view: Security Services. Mapped security capability: Diagnostic security Mapped feature: Diagnostic security; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 30 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00414 | SUV2_REQ 99 The server shall verify the programmed software module by calculating a checksum on the programmed data by matching this checksum with a pre-calculated checksum.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 99 The server shall verify the programmed software module by calculating a checksum on the programmed data by matching this checksum with a pre-calculated checksum. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 30 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00415 | SUV2_REQ 100 The pre-calculated checksum shall be provided as part of the data submitted with the TransferData service request.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Software Update; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 100 The pre-calculated checksum shall be provided as part of the data submitted with the TransferData service request. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Software Update; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 30 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00416 | Page 31 SUV2_INFO 111 Implementation Hint: The following generator polynomial with the following initial value are suggested to be used for calculation of the checksum: G(X) = x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1 Initial value: 0xFFFFFFFF 8.2.1 Request SUV2_REQ 102 The server shall support the routine request according to Table 15.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Page 31 SUV2_INFO 111 Implementation Hint: The following generator polynomial with the following initial value are suggested to be used for calculation of the checksum: G(X) = x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1 Initial value: 0xFFFFFFFF 8.2.1 Request SUV2_REQ 102 The server shall support the routine request according to Table 15. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 31 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00417 | Table 15: Routine 0x2202 Request Format Byte Description Cvt Hex #1 RoutineControl Request SID M 0x31 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) M 0x22 #4 routineIdentifier (LSB) M 0x02 8.2.2 Positive Response SUV2_REQ 103 The server shall support the routine positive response according to Table 16.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Table 15: Routine 0x2202 Request Format Byte Description Cvt Hex #1 RoutineControl Request SID M 0x31 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) M 0x22 #4 routineIdentifier (LSB) M 0x02 8.2.2 Positive Response SUV2_REQ 103 The server shall support the routine positive response according to Table 16. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 31 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00418 | Page 32 8.2.4 Routine 0x2202 Parameters 8.2.4.1 Parameter routineStatus routineResult SUV2_REQ 105 The server shall support parameter routineStatus routineResult formatted according to Table 17.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Page 32 8.2.4 Routine 0x2202 Parameters 8.2.4.1 Parameter routineStatus routineResult SUV2_REQ 105 The server shall support parameter routineStatus routineResult formatted according to Table 17. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 32 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00419 | SUV2_REQ 106 The server shall respond with a positive response code without erasing memory if the specified memory area has already been completely erased (or is writable) at the time the service is requested.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 106 The server shall respond with a positive response code without erasing memory if the specified memory area has already been completely erased (or is writable) at the time the service is requested. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 32 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00420 | SUV2_INFO 113 In order to satisfy stability requirements, the erasing of the boot loader may require that the current boot loader be copied into another non-volatile memory area before the boot loader memory is erased, see Annex A for an implementation hint.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Secure Boot and Application State Control | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: SUV2_INFO 113 In order to satisfy stability requirements, the erasing of the boot loader may require that the current boot loader be copied into another non-volatile memory area before the boot loader memory is erased, see Annex A for an implementation hint. Engineering expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Engineering interpretation: Security view: Secure Boot and Application State Control. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 32 Classification: Reclassified as Assumption Mandatory level: May Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00421 | SUV2_REQ 107 In case the non volatile memory area is currently hosting a bootloader copy, meaning there is an ongoing bootloader update procedure, the ECU shall ensure that this memory area shall not be erased until a valid bootloader is flashed in the bootloader memory area.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Secure Software Update; Secure Boot and Application State Control | Interface: None Architecture: Hardware Platform Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 107 In case the non volatile memory area is currently hosting a bootloader copy, meaning there is an ongoing bootloader update procedure, the ECU shall ensure that this memory area shall not be erased until a valid bootloader is flashed in the bootloader memory area. Engineering expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Engineering interpretation: Security view: Secure Software Update; Secure Boot and Application State Control. Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 32 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00422 | SUV2_REQ 108 When the addressAndLengthFormatIdentifier parameter is set to a value > 0x00 the server shall reset the following software and data identification DIDs to their default values (see section Software and data identification): • If boot software (any part) is erased, reset 0xF180, 0xF191 and 0xF187 to default values (some of the DIDs will be automatically erased as a consequence of erasing one or more modules).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Boot and Application State Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 108 When the addressAndLengthFormatIdentifier parameter is set to a value > 0x00 the server shall reset the following software and data identification DIDs to their default values (see section Software and data identification): • If boot software (any part) is erased, reset 0xF180, 0xF191 and 0xF187 to default values (some of the DIDs will be automatically erased as a consequence of erasing one or more modules). Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Boot and Application State Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 32 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00423 | SUV2_REQ 109 The erasing of memory shall not prevent the client from starting a data transfer using the TransferData (0x36) service, i.e., the erasing of memory shall proceed in parallel with data transfer in case for ECUs implementing Automatic erase.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Secure Software Update; Secure Communication and Boundary Control; Security Logging and Event Handling | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 109 The erasing of memory shall not prevent the client from starting a data transfer using the TransferData (0x36) service, i.e., the erasing of memory shall proceed in parallel with data transfer in case for ECUs implementing Automatic erase. Engineering expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Engineering interpretation: Security view: Secure Software Update; Secure Communication and Boundary Control; Security Logging and Event Handling. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 32 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00424 | Page 33 8.3.1 Routine Request SUV2_REQ 110 The server shall support the routine request according to Table 18.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Page 33 8.3.1 Routine Request SUV2_REQ 110 The server shall support the routine request according to Table 18. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 33 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00425 | 8.3.2 Routine Positive Response SUV2_REQ 111 The server shall support the routine positive response according to Table 19.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 8.3.2 Routine Positive Response SUV2_REQ 111 The server shall support the routine positive response according to Table 19. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 33 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00426 | Page 34 8.3.3 Routine Negative Response SUV2_REQ 112 8.3.4 Routine 0xFF00 Parameters 8.3.4.1 Parameter addressAndLengthFormatIdentifier SUV2_REQ 113 The server shall support parameter addressAndLengthFormatIdentifier formatted according to Table 20.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Page 34 8.3.3 Routine Negative Response SUV2_REQ 112 8.3.4 Routine 0xFF00 Parameters 8.3.4.1 Parameter addressAndLengthFormatIdentifier SUV2_REQ 113 The server shall support parameter addressAndLengthFormatIdentifier formatted according to Table 20. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 34 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00427 | E.g., 02, Module 2 (Application SW module) M 0x02 – 0xFF Physical memory range erase: Refer to ISO 14229-1 Table H1 M C = Mandatory if required to meet the performance requirements SUV2_REQ 62 & SUV2_REQ 63.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Application Software Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: E.g., 02, Module 2 (Application SW module) M 0x02 – 0xFF Physical memory range erase: Refer to ISO 14229-1 Table H1 M C = Mandatory if required to meet the performance requirements SUV2_REQ 62 & SUV2_REQ 63. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 34 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00428 | SUV2_REQ 114 When the addressAndLengthFormatIdentifier is set to 0x01 the defined module to index mapping shall apply for the memoryStartAddress according to Table 21.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 114 When the addressAndLengthFormatIdentifier is set to 0x01 the defined module to index mapping shall apply for the memoryStartAddress according to Table 21. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 34 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00429 | Table 21: Module to Index Mapping Value Mapped to 0x01 Bootloader 0x02 Application 0x03 Application Data 0x04 – 0xFF System Specific 8.3.4.2 Paramter routineStatus routineResult SUV2_REQ 115 The server shall support parameter routineStatus routineResult formatted according to Table 22.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Secure Software Update; Secure Boot and Application State Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Table 21: Module to Index Mapping Value Mapped to 0x01 Bootloader 0x02 Application 0x03 Application Data 0x04 – 0xFF System Specific 8.3.4.2 Paramter routineStatus routineResult SUV2_REQ 115 The server shall support parameter routineStatus routineResult formatted according to Table 22. Engineering expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Engineering interpretation: Security view: Secure Software Update; Secure Boot and Application State Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 34 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00430 | SUV2_REQ 143 This RoutineIdentifier shall be able to execute independent from programming sequence SUV2_INFO 124 The client may opt to execute this routineIdentifier as a standalone procedure to check to perform a software consistency check.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Software Update | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 143 This RoutineIdentifier shall be able to execute independent from programming sequence SUV2_INFO 124 The client may opt to execute this routineIdentifier as a standalone procedure to check to perform a software consistency check. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Software Update. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 35 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00431 | SUV2_REQ 116 The server shall check whether the individual modules are complete and compatible with one another.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 116 The server shall check whether the individual modules are complete and compatible with one another. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 35 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00432 | In addition, a check shall be made to determine whether the software is compatible with the hardware version (e.g., variants of sensors/actuators) and other data structures (e.g., EEPROM data).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Application Software Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: In addition, a check shall be made to determine whether the software is compatible with the hardware version (e.g., variants of sensors/actuators) and other data structures (e.g., EEPROM data). Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 35 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00433 | SUV2_REQ 117 The method used to check compatibility/consistency shall be determined by the supplier in consultation with the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 117 The method used to check compatibility/consistency shall be determined by the supplier in consultation with the vehicle manufacturer. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 35 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00434 | SUV2_REQ 118 The consistency check shall be carried out solely by the server.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 118 The consistency check shall be carried out solely by the server. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 35 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00435 | SUV2_REQ 119 The server shall verify the integrity of the software as a part of the consistency check.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 119 The server shall verify the integrity of the software as a part of the consistency check. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 35 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00436 | SUV2_REQ 120 The integrity information shall be supplied to the server before the software is updated.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Secure Software Update; Data Authenticity and Integrity Verification | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 120 The integrity information shall be supplied to the server before the software is updated. Engineering expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Engineering interpretation: Security view: Secure Software Update; Data Authenticity and Integrity Verification. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 35 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00437 | SUV2_REQ 121 The integrity check shall be carried out solely by the server.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 121 The integrity check shall be carried out solely by the server. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 35 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00438 | 8.4.1 Request SUV2_REQ 122 The server shall support the routine request according to Table 23.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 8.4.1 Request SUV2_REQ 122 The server shall support the routine request according to Table 23. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 35 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00439 | Page 36 8.4.2 Positive Response SUV2_REQ 123 The server shall support the routine positive response according to Table 24.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Page 36 8.4.2 Positive Response SUV2_REQ 123 The server shall support the routine positive response according to Table 24. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 36 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00440 | Table 24: Routine 0xFF01 Positive Response Format #1 RoutineControl Response SID M 0x71 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) checkProgrammingDependencies[byte#1] M 0xFF #4 routineIdentifier (LSB) checkProgrammingDependencies [byte#2] M 0x01 #5 routineStatus routineResult M 0x00-0xFF #6 … #7 routineResultProofLength M Uint16 #8 … #n routineResultProof M Uint8[] 8.4.3 Negative Response SUV2_REQ 124 8.4.4 Routine 0xFF01 Parameters 8.4.4.1 Parameter routineStatus routineResult SUV2_REQ 125 The server shall support parameter routineStatus routineResult formatted according to Table 25.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Software Update | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Table 24: Routine 0xFF01 Positive Response Format #1 RoutineControl Response SID M 0x71 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) checkProgrammingDependencies[byte#1] M 0xFF #4 routineIdentifier (LSB) checkProgrammingDependencies [byte#2] M 0x01 #5 routineStatus routineResult M 0x00-0xFF #6 … #7 routineResultProofLength M Uint16 #8 … #n routineResultProof M Uint8[] 8.4.3 Negative Response SUV2_REQ 124 8.4.4 Routine 0xFF01 Parameters 8.4.4.1 Parameter routineStatus routineResult SUV2_REQ 125 The server shall support parameter routineStatus routineResult formatted according to Table 25. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Software Update. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 36 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00441 | Table 25: Routine 0xFF01 routineStatus routineResult Format Hex Description Cvt 0x00 correctResult M 0x01 incorrectResult - General Failure M 0x02 incorrectResult error SW – HW M 0x03 incorrectResult error SW – SW M 0x04 IncorrectResult One or more modules are not programmed or are incorrectly programmed M 0x05 incorrectResult One or more modules failed when verifying the integrity of the software M 0x06 – 0xFF Reserved M SUV2_REQ 126 The server shall set routineResult as 0x00 (correctResult) if the integrity verification is valid, the software was successfully installed and the installed software are compatible between all software module and the software is compatible with the ECU hardware.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA | Interface: OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: Table 25: Routine 0xFF01 routineStatus routineResult Format Hex Description Cvt 0x00 correctResult M 0x01 incorrectResult - General Failure M 0x02 incorrectResult error SW – HW M 0x03 incorrectResult error SW – SW M 0x04 IncorrectResult One or more modules are not programmed or are incorrectly programmed M 0x05 incorrectResult One or more modules failed when verifying the integrity of the software M 0x06 – 0xFF Reserved M SUV2_REQ 126 The server shall set routineResult as 0x00 (correctResult) if the integrity verification is valid, the software was successfully installed and the installed software are compatible between all software module and the software is compatible with the ECU hardware. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA. Interface view: OEM/Customer Review Interface. Architecture view: Application Software; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Application software behavior; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: Application Software; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 36 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00442 | If the server set routineResult as 0x00 (CorrectResult) the server shall reject with NRC 0x24 the following diagnostic services and routines until a new SDSC is provided:Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: If the server set routineResult as 0x00 (CorrectResult) the server shall reject with NRC 0x24 the following diagnostic services and routines until a new SDSC is provided: Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security. Architecture view: Security Services. Mapped security capability: Diagnostic security Mapped feature: Diagnostic security Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 36 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00443 | 8.4.4.3 Parameter routineResultProof SUV2_REQ 171 The server shall hash the receipt number with the routineStatus routineResult parameter, in this respective order.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 8.4.4.3 Parameter routineResultProof SUV2_REQ 171 The server shall hash the receipt number with the routineStatus routineResult parameter, in this respective order. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 37 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00444 | SUV2_REQ 172 The hash algorithm shall be SHA512.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 172 The hash algorithm shall be SHA512. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 37 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00445 | SUV2_REQ 173 The server shall sign the hashed output using the receipt-keys.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Key and Certificate Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 173 The server shall sign the hashed output using the receipt-keys. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Key and Certificate Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 37 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00446 | SUV2_REQ 174 The server shall use ED25519 as signature algorithm.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 174 The server shall use ED25519 as signature algorithm. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 37 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00447 | SUV2_REQ 175 The server shall return in the parameter routineResultProof the signed hash.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 175 The server shall return in the parameter routineResultProof the signed hash. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 37 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00448 | Page 38 Figure 5: diagram for signing of software update results 8.4.4.4 Client behaviour after server software verification SUV2_REQ 183 The client shall send the Servers routineStatus routineResult response to the backend.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Secure Software Update; Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA | Interface: OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: Page 38 Figure 5: diagram for signing of software update results 8.4.4.4 Client behaviour after server software verification SUV2_REQ 183 The client shall send the Servers routineStatus routineResult response to the backend. Engineering expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Engineering interpretation: Security view: Secure Software Update; Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA. Interface view: OEM/Customer Review Interface. Architecture view: Application Software; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Application software behavior; Secure software update and flash readiness; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: Application Software; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 38 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00449 | SUV2_REQ 176 Once a SDSC has being accepted by the server, the server shall store in the NVM the receipt number sent over as part of the EMP request.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 176 Once a SDSC has being accepted by the server, the server shall store in the NVM the receipt number sent over as part of the EMP request. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 38 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00450 | Once a SDSC has being accepted by the server, the server shall accept the following diagnostic services and routines: SUV2_REQ 177 • Routine 0xFF00 Erase Memory SUV2_REQ 178 • Service 0x34 RequestDownload SUV2_REQ 179 • Service 0x36 TransferData SUV2_REQ 180 • Service 0x37 RequestTransferExitExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Once a SDSC has being accepted by the server, the server shall accept the following diagnostic services and routines: SUV2_REQ 177 • Routine 0xFF00 Erase Memory SUV2_REQ 178 • Service 0x34 RequestDownload SUV2_REQ 179 • Service 0x36 TransferData SUV2_REQ 180 • Service 0x37 RequestTransferExit Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security. Architecture view: Security Services. Mapped security capability: Diagnostic security Mapped feature: Diagnostic security Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 38 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00451 | Page 39 8.5.1 Request SUV2_REQ 129 The server shall support the routine request according to Table 26.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Page 39 8.5.1 Request SUV2_REQ 129 The server shall support the routine request according to Table 26. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 39 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00452 | Table 26: Routine 0xCAFE Request Format Byte Description Cvt Hex #1 RoutineControl Request SID M 0x31 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) M 0xCA #4 routineIdentifier (LSB) M 0xFE #5 … #n EMP Message M 0x00 – 0xFF 8.5.2 Positive Response SUV2_REQ 130 The server shall support the routine positive response according to Table 27.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Table 26: Routine 0xCAFE Request Format Byte Description Cvt Hex #1 RoutineControl Request SID M 0x31 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) M 0xCA #4 routineIdentifier (LSB) M 0xFE #5 … #n EMP Message M 0x00 – 0xFF 8.5.2 Positive Response SUV2_REQ 130 The server shall support the routine positive response according to Table 27. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 39 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00453 | #n EMP Message M 0x00-0xFF 8.5.3 Negative Response SUV2_REQ 131 SUV2_REQ 132 The server shall support the routine negative response according to CVS33.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: #n EMP Message M 0x00-0xFF 8.5.3 Negative Response SUV2_REQ 131 SUV2_REQ 132 The server shall support the routine negative response according to CVS33. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 39 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00454 | 8.5.4 Routine 0xCAFE Parameters 8.5.4.1 Parameter EMP Message SUV2_REQ 133 The server shall support the parameter EMP message according to CVS33.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 8.5.4 Routine 0xCAFE Parameters 8.5.4.1 Parameter EMP Message SUV2_REQ 133 The server shall support the parameter EMP message according to CVS33. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 39 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00455 | Page 40 9 Software Verification and Encryption Requirements SUV2_INFO 117 The information required for the server for verifying software integrity and optionally decrypt the transported data from a trusted source, is described in a Software Data Security Container (SDSC).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA; Secure communication | Interface: OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: Page 40 9 Software Verification and Encryption Requirements SUV2_INFO 117 The information required for the server for verifying software integrity and optionally decrypt the transported data from a trusted source, is described in a Software Data Security Container (SDSC). Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA; Secure communication. Interface view: OEM/Customer Review Interface. Architecture view: Security Services; OEM/Customer Review Interface. Mapped security capability: Secure communication Mapped feature: Secure communication; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: Security Services; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 40 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00456 | 9.1 General Requirements on SDSC 9.1.1 SDSC Structure SUV2_REQ 134 The server shall implement SDSC structure as defined in CVS154.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 9.1 General Requirements on SDSC 9.1.1 SDSC Structure SUV2_REQ 134 The server shall implement SDSC structure as defined in CVS154. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 40 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00457 | SUV2_REQ 184 The range start field shall be the memory address offset from the dataLocator field.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Hardware Platform Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 184 The range start field shall be the memory address offset from the dataLocator field. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 40 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00458 | SUV2_REQ 185 The range length field shall be the number of bytes to be verified.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 185 The range length field shall be the number of bytes to be verified. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 40 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00459 | SUV2_REQ 161 The supplier shall propose for each software module an identification to be used in dataLocator field in SDSC.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 161 The supplier shall propose for each software module an identification to be used in dataLocator field in SDSC. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: Application Software; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: Application Software; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 40 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00460 | SUV2_REQ 168 The vehicle manufacturer shall review and accept the proposals for every dataLocator.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: OEM/Customer Review Interface Architecture: Compliance Process; OEM/Customer Review Interface Status: Missing security feature | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 168 The vehicle manufacturer shall review and accept the proposals for every dataLocator. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Interface view: OEM/Customer Review Interface. Architecture view: Compliance Process; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: Compliance Process; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 40 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00461 | The start address shall be used as an offset in the software module while the length can be utilized to know which areas of the software module are to be verified and/or decrypted.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: The start address shall be used as an offset in the software module while the length can be utilized to know which areas of the software module are to be verified and/or decrypted. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 40 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00462 | 9.1.2 SDSC Sanity Check SUV2_REQ 135 Before accepting the SDSC as valid, the server shall perform the sanity check of the received SDSC as defined in CVS154.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 9.1.2 SDSC Sanity Check SUV2_REQ 135 Before accepting the SDSC as valid, the server shall perform the sanity check of the received SDSC as defined in CVS154. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 40 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00463 | SUV2_REQ 138 If the sanity check returns fail/invalid, the server shall reject SDSC as described in CVS34.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 138 If the sanity check returns fail/invalid, the server shall reject SDSC as described in CVS34. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 41 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00464 | 9.2 Software Verification SUV2_REQ 152 The server shall validate each VerificationEntry found in the SDSC.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA | Interface: OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: 9.2 Software Verification SUV2_REQ 152 The server shall validate each VerificationEntry found in the SDSC. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA. Interface view: OEM/Customer Review Interface. Architecture view: Application Software; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Application software behavior; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: Application Software; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 41 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00465 | SUV2_REQ 153 Software hashes in the SDSC shall be verified by the server considering the ranges which are stated in the SDSC.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Application Software Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 153 Software hashes in the SDSC shall be verified by the server considering the ranges which are stated in the SDSC. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 41 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00466 | SUV2_REQ 154 The Ranges dictates the data range that the server shall begin, and end read from NVM for hashing.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 154 The Ranges dictates the data range that the server shall begin, and end read from NVM for hashing. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 41 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00467 | SUV2_INFO 126 The Ranges can be one or several if there are gaps between memory areas which shall be excluded from the hash calculation for some reason.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: Hardware Platform Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_INFO 126 The Ranges can be one or several if there are gaps between memory areas which shall be excluded from the hash calculation for some reason. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 41 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00468 | SUV2_REQ 155 When hashing software, the whole memory range, including erased-only bytes of a memory module, shall be possible to include in the hash calculation.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Application Software Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 155 When hashing software, the whole memory range, including erased-only bytes of a memory module, shall be possible to include in the hash calculation. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 41 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00469 | Figure 6: Erased-only bytes of a memory module SUV2_REQ 156 The byte value of an erased data byte (typically FF or 00) depends on the MCU/Flash memory and shall be specified by the software supplier as an input for the hashing process.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Secure Software Update; Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: Figure 6: Erased-only bytes of a memory module SUV2_REQ 156 The byte value of an erased data byte (typically FF or 00) depends on the MCU/Flash memory and shall be specified by the software supplier as an input for the hashing process. Engineering expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Engineering interpretation: Security view: Secure Software Update; Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: Application Software; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Application software behavior; Secure software update and flash readiness Mapped interface: OEM/Customer Review Interface Mapped architecture element: Application Software; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 41 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00470 | Page 42 SUV2_REQ 157 The server shall be able to verify that erased-only blocks covered in range of memory are erased.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification | Interface: None Architecture: Hardware Platform Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Page 42 SUV2_REQ 157 The server shall be able to verify that erased-only blocks covered in range of memory are erased. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification. Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 42 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00471 | SUV2_REQ 158 When the server has verified all verificationEntries, a result OK/NOT_OK shall be returned.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA | Interface: OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 158 When the server has verified all verificationEntries, a result OK/NOT_OK shall be returned. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA. Interface view: OEM/Customer Review Interface. Architecture view: Backend and IT Systems; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Backend and IT integration; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: Backend and IT Systems; OEM/Customer Review Interface Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 42 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00472 | SUV2_REQ 159 If NOT_OK is returned, the server shall not accept the new software for execution.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Application Software Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 159 If NOT_OK is returned, the server shall not accept the new software for execution. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 42 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00473 | SUV2_REQ 160 If OK is returned, the server shall accept that installed software is valid in terms of integrity.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 160 If OK is returned, the server shall accept that installed software is valid in terms of integrity. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 42 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00474 | SUV2_INFO 131 The server may execute other checks to verify the software before concluding if the installed software shall be accepted.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SUV2_INFO 131 The server may execute other checks to verify the software before concluding if the installed software shall be accepted. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 42 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00475 | 9.3 Software decryption SUV2_REQ 147 For the received data, where a match is found in the EncryptionEntry of the DSC, the server shall initialize a cipher if not previously initialized.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Application Software Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 9.3 Software decryption SUV2_REQ 147 For the received data, where a match is found in the EncryptionEntry of the DSC, the server shall initialize a cipher if not previously initialized. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 42 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00476 | SUV2_REQ 148 An initialized data (i.e., cipher scheme) shall be kept active until no more received data matches the current EncryptionEntry.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 148 An initialized data (i.e., cipher scheme) shall be kept active until no more received data matches the current EncryptionEntry. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 42 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00477 | SUV2_REQ 149 The cipher shall be reinitialized for each new Encryption entry.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 149 The cipher shall be reinitialized for each new Encryption entry. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 42 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00478 | SUV2_REQ 150 According to best practise received data shall be decrypted “on the fly” before storing to NVM.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: SUV2_REQ 150 According to best practise received data shall be decrypted “on the fly” before storing to NVM. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 42 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00479 | Other methods shall be agreed upon with OEM.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Other methods shall be agreed upon with OEM. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 42 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00480 | SUV2_INFO 134 The received data to decrypt may only be parts of a software module and it will be based on the range defined.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | None | Interface: None Architecture: Application Software Status: Missing security feature, interface | Medium Needed | DetailsFull requirement statement: SUV2_INFO 134 The received data to decrypt may only be parts of a software module and it will be based on the range defined. Engineering expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Engineering interpretation: Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 42 Classification: Reclassified as Constraint Mandatory level: May Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00481 | Note that more than one Address field can be specified if there are one or more areas within a memory module which must be excluded in the hash due to some logical restrictions (e.g., boot writing internal data to such area during programming).Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Secure Software Update; Secure Boot and Application State Control; Secure Communication and Boundary Control; Security Logging and Event Handling | Interface: None Architecture: Hardware Platform Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Note that more than one Address field can be specified if there are one or more areas within a memory module which must be excluded in the hash due to some logical restrictions (e.g., boot writing internal data to such area during programming). Engineering expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Engineering interpretation: Security view: Secure Software Update; Secure Boot and Application State Control; Secure Communication and Boundary Control; Security Logging and Event Handling. Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 48 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00482 | S-record Memory layout #00868000 #008AFFFF #00930000 #00BFFFFF #008B0000 #0092FFFF Module hashData #00AFAAAA #00AFAAAB When ECU recieves data that matches an address range in an EncryptionEntry (here in Module B), the server must decrypt the data received by TransferData request.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Software Update | Interface: None Architecture: Hardware Platform Status: Missing interface | Medium Not needed | DetailsFull requirement statement: S-record Memory layout #00868000 #008AFFFF #00930000 #00BFFFFF #008B0000 #0092FFFF Module hashData #00AFAAAA #00AFAAAB When ECU recieves data that matches an address range in an EncryptionEntry (here in Module B), the server must decrypt the data received by TransferData request. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Software Update. Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 50 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00483 | Module B is encrypted meaning that when the server receives data within a range (given as address and size in RequestDownload) the server must decrypt the data before storing it.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Software Update | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Module B is encrypted meaning that when the server receives data within a range (given as address and size in RequestDownload) the server must decrypt the data before storing it. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Software Update. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS123-2.pdf Source Markdown: converted/markdown-cleaned/CVS123-2.md Page reference: page 50 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00484 | The User shall apply the latest version of this CVS124.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The User shall apply the latest version of this CVS124. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 1 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00485 | Internal Page 2 (90) Foreword This CVS124 contains requirement specification for TRATON GROUP and may be used by all within TRATON Group, if applicable.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: None Status: Missing security feature, interface, architecture | Low Not needed | DetailsFull requirement statement: Internal Page 2 (90) Foreword This CVS124 contains requirement specification for TRATON GROUP and may be used by all within TRATON Group, if applicable. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Traceability needs review before this requirement can be used as design evidence. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 2 Classification: Needs Manual Markdown Correction Mandatory level: May Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ-AUTO-00486 | Any review of CVS124 shall only be done in agreement with the involved departments stated in the table on the first page under section “Technical responsibility”.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Compliance Process Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Any review of CVS124 shall only be done in agreement with the involved departments stated in the table on the first page under section “Technical responsibility”. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 2 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00487 | • Affiliate means any legal entity that directly or indirectly controls, is controlled by, or is commonly controlled with TRATON SE, it is being understood that “control” shall mean ownership of at least 50% of the voting rights or interest in the issued share capital, including for the avoidance of doubt any branch.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: • Affiliate means any legal entity that directly or indirectly controls, is controlled by, or is commonly controlled with TRATON SE, it is being understood that “control” shall mean ownership of at least 50% of the voting rights or interest in the issued share capital, including for the avoidance of doubt any branch. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 2 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00488 | 4 Terms, definitions and abbreviations 4.1 Terms Table 1 – Definition of Terms Term Definition Shall This word, or the terms "Required" or "Must", means that the definition is an absolute requirement of the specification.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Needed | DetailsFull requirement statement: 4 Terms, definitions and abbreviations 4.1 Terms Table 1 – Definition of Terms Term Definition Shall This word, or the terms "Required" or "Must", means that the definition is an absolute requirement of the specification. Engineering expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 6 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00489 | Shall not This phrase, or the phrase "Must not", means that the definition is an absolute prohibition of the specification.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Shall not This phrase, or the phrase "Must not", means that the definition is an absolute prohibition of the specification. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 6 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00490 | Should This word, or the adjective “Recommended”, means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications shall be understood and carefully weighed before choosing a different course.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Should This word, or the adjective “Recommended”, means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications shall be understood and carefully weighed before choosing a different course. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 6 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00491 | Should not This phrase, or the phrase “Not recommended”, means that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Should not This phrase, or the phrase “Not recommended”, means that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 6 Classification: Not Applicable Mandatory level: Should Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00492 | May This word, or the adjective “Optional”, means that an item is truly optional.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | None | Interface: None Architecture: None Status: Missing security feature, interface, architecture | Medium Needed | DetailsFull requirement statement: May This word, or the adjective “Optional”, means that an item is truly optional. Engineering expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Engineering interpretation: Traceability needs review before this requirement can be used as design evidence. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 6 Classification: Reclassified as Assumption Mandatory level: May Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00493 | One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 6 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00494 | An implementation which does not include a particular option shall be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: An implementation which does not include a particular option shall be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 6 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00495 | In the same vein an implementation which does include a particular option shall be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: In the same vein an implementation which does include a particular option shall be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides). Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 6 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00496 | Internal Page 7 (90) ISO International Organization for Standardization non-Def Non-default diagnostic session ODX Open Diagnostic Data Exchange, ODX-Standard (ASAM MCD-2D) Prg Programming diagnostic session SPN Suspected Parameter Number PDU Protocol Data Unit SID Service Identification Data IVD Integrity Validation Data RBAC Role Base Access Control RBACC RBAC Configuration SPRMIB Suppress Positive Response Message Indication Bit A_ASCIISTRING ODX BASE-DATA-TYPE for an ASCII coded character field (ISO 8859-1) min-max-length zero The bit length of the ODX element DOP (DATA-OBJECT-PROP) is variable; minimal and maximal length is given in bytes; the termination is ZERO for binary and ‘NULL’ for ASCII 4.3 Conventions Table 3 – Conventions Implementation Description M Mandatory Mandatory data marked as ‘M’ always shall be returned.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security | Interface: OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: Internal Page 7 (90) ISO International Organization for Standardization non-Def Non-default diagnostic session ODX Open Diagnostic Data Exchange, ODX-Standard (ASAM MCD-2D) Prg Programming diagnostic session SPN Suspected Parameter Number PDU Protocol Data Unit SID Service Identification Data IVD Integrity Validation Data RBAC Role Base Access Control RBACC RBAC Configuration SPRMIB Suppress Positive Response Message Indication Bit A_ASCIISTRING ODX BASE-DATA-TYPE for an ASCII coded character field (ISO 8859-1) min-max-length zero The bit length of the ODX element DOP (DATA-OBJECT-PROP) is variable; minimal and maximal length is given in bytes; the termination is ZERO for binary and ‘NULL’ for ASCII 4.3 Conventions Table 3 – Conventions Implementation Description M Mandatory Mandatory data marked as ‘M’ always shall be returned. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security. Interface view: OEM/Customer Review Interface. Architecture view: Security Services; OEM/Customer Review Interface. Mapped security capability: Diagnostic security Mapped feature: Diagnostic security; Secure software update and flash readiness; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: Security Services; OEM/Customer Review Interface Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 7 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00497 | If valid data is not needed for the use-case and system at hand, default values should be used.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: If valid data is not needed for the use-case and system at hand, default values should be used. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 7 Classification: Not Applicable Mandatory level: Should Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00498 | E Mandatory for ECUs which shall be compliant with OBD legislation Worldwide like ISO27145,J1979 etc C Conditional U User optional.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: E Mandatory for ECUs which shall be compliant with OBD legislation Worldwide like ISO27145,J1979 etc C Conditional U User optional. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 7 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00499 | Shall be agreed between the supplier and the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: Shall be agreed between the supplier and the vehicle manufacturer. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 7 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_UDS-0001 | Internal Page 8 (90) 5 Requirements 5.1 General RequirementsThe implementation of the client and the server shall be compliant with ISO 14229-1 with the clarifications, extensions and exceptions stated in this specification.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | High Not needed | DetailsFull requirement statement: Internal Page 8 (90) 5 Requirements 5.1 General Requirements REQ_UDS 0001 The implementation of the client and the server shall be compliant with ISO 14229-1 with the clarifications, extensions and exceptions stated in this specification. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 8 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0002 | All deviations and extensions shall be agreed with the applicable vehicle manufacturer and shall be documented.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: REQ_UDS 0002 All deviations and extensions shall be agreed with the applicable vehicle manufacturer and shall be documented. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 8 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_UDS-0003 | 5.2 ECU Identification Requirements 5.2.1 Used data identifier in order to identify an ECUTable 5 -Data identifiers used at ECU identification DID Description/ Name Application Boot loader Changing Def Non- Def Def Ext Prg Ext 0xF180 bootSoftwareIdentificationDataIdentifier ● ● ● ● ● SUPPLIER 0xF181 applicationSoftwareIdentificationDataIdentifier ● ● ● ● ● SUPPLIER 0xF182 applicationDataIdentificationDataIdentifier ● ● ● ● ● SUPPLIER 0xF186 ActiveDiagnosticSessionDataIdentifier ● ● ● ● ● INTERNAL 0xF187 vehicleManufacturerSparePartNumberDataIdentifier ● ○ ● ○ ○ SUPPLIER 0xF188 vehicleManufacturerECUSoftwareNumberDataIdent ifier ● ● ● ● ● SUPPLIER 0xF189 vehicleManufacturerECUSoftwareVersionNumberD ataIdentifier ● ● ● ● ● SUPPLIER 0xF18A systemSupplierIdentifierDataIdentifier ● ● - - - SUPPLIER 0xF18B ECUManufacturingDateDataIdentifier ● ● ● ● ● SUPPLIER 0xF18C ECUSerialNumberDataIdentifier ● ● ● ● ● SUPPLIER 0xF190 VINDataIdentifier ● ○ ● ● ● DIAG 0xF191 vehicleManufacturerECUHardwareNumberDataIde ntifier ● ● ● ● ● SUPPLIER 0xF192 systemSupplierECUHardwareNumberDataIdentifier ● ● - - - SUPPLIER 0xF193 systemSupplierECUHardwareVersionNumberDataI dentifier ● ● - - - SUPPLIER 0xF194 systemSupplierECUSoftwareNumberDataIdentifier ● ● - - - SUPPLIERExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control; Cybersecurity Evidence and DIA; Supplier Development and Production Hardening | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: 5.2 ECU Identification Requirements 5.2.1 Used data identifier in order to identify an ECU REQ_UDS 0003 Table 5 -Data identifiers used at ECU identification DID Description/ Name Application Boot loader Changing Def Non- Def Def Ext Prg Ext 0xF180 bootSoftwareIdentificationDataIdentifier ● ● ● ● ● SUPPLIER 0xF181 applicationSoftwareIdentificationDataIdentifier ● ● ● ● ● SUPPLIER 0xF182 applicationDataIdentificationDataIdentifier ● ● ● ● ● SUPPLIER 0xF186 ActiveDiagnosticSessionDataIdentifier ● ● ● ● ● INTERNAL 0xF187 vehicleManufacturerSparePartNumberDataIdentifier ● ○ ● ○ ○ SUPPLIER 0xF188 vehicleManufacturerECUSoftwareNumberDataIdent ifier ● ● ● ● ● SUPPLIER 0xF189 vehicleManufacturerECUSoftwareVersionNumberD ataIdentifier ● ● ● ● ● SUPPLIER 0xF18A systemSupplierIdentifierDataIdentifier ● ● - - - SUPPLIER 0xF18B ECUManufacturingDateDataIdentifier ● ● ● ● ● SUPPLIER 0xF18C ECUSerialNumberDataIdentifier ● ● ● ● ● SUPPLIER 0xF190 VINDataIdentifier ● ○ ● ● ● DIAG 0xF191 vehicleManufacturerECUHardwareNumberDataIde ntifier ● ● ● ● ● SUPPLIER 0xF192 systemSupplierECUHardwareNumberDataIdentifier ● ● - - - SUPPLIER 0xF193 systemSupplierECUHardwareVersionNumberDataI dentifier ● ● - - - SUPPLIER 0xF194 systemSupplierECUSoftwareNumberDataIdentifier ● ● - - - SUPPLIER Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control; Cybersecurity Evidence and DIA; Supplier Development and Production Hardening. Mapped security capability: None Mapped feature: Secure communication and freshness protection Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 8 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0004 | Internal Page 10 (90) 5.2.1.1 DID 0xF180 bootSoftwareIdentificationDataIdentifierTable 6 – Description of DID 0xF180 bootSoftwareIdentificationDataIdentifier 0xF180 Name : bootSoftwareIdentificationDataIdentifier Byte Data #1 numberOfModules 1-Byte-A_UINT32 M 0x01 0x01 #2 : #14 Boot software identifier #1: : M : M 0x7E .Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: Internal Page 10 (90) 5.2.1.1 DID 0xF180 bootSoftwareIdentificationDataIdentifier REQ_UDS 0004 Table 6 – Description of DID 0xF180 bootSoftwareIdentificationDataIdentifier 0xF180 Name : bootSoftwareIdentificationDataIdentifier Byte Data #1 numberOfModules 1-Byte-A_UINT32 M 0x01 0x01 #2 : #14 Boot software identifier #1: : M : M 0x7E . Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 10 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0005 | 0x20This DID shall be stored under flash memory module in flash memory.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update | Interface: None Architecture: Hardware Platform Status: Missing interface | High Not needed | DetailsFull requirement statement: 0x20 REQ_UDS 0005 This DID shall be stored under flash memory module in flash memory. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0006 | 5.2.1.2 DID 0xF181 applicationSoftwareIdentificationDataIdentifierTable 7 – Description of DID 0xF181 applicationSoftwareIdentificationDataIdentifier 0xF181 Name : applicationSoftwareIdentificationDataIdentifier Byte Data #1 numberOfModules 1-Byte-A_UINT32 M 0x01 0x02 – 0xFF 0x01 #2 : #14 Application software identifier #1: : M 0x7E 0x7E 0x20 : : : #n – 12 : #n Application software identifier #m: : C 0x7E 0x7E 0x20Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: 5.2.1.2 DID 0xF181 applicationSoftwareIdentificationDataIdentifier REQ_UDS 0006 Table 7 – Description of DID 0xF181 applicationSoftwareIdentificationDataIdentifier 0xF181 Name : applicationSoftwareIdentificationDataIdentifier Byte Data #1 numberOfModules 1-Byte-A_UINT32 M 0x01 0x02 – 0xFF 0x01 #2 : #14 Application software identifier #1: : M 0x7E 0x7E 0x20 : : : #n – 12 : #n Application software identifier #m: : C 0x7E 0x7E 0x20 Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 10 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0007 | Internal Page 11 (90) REQ_UDS 0231 5.2.1.3 DID 0xF182 applicationDataIdentificationDataIdentifierTable 8 – Description of DID 0xF182 applicationDataIdentificationDataIdentifier 0xF182 Name: applicationDataIdentificationDataIdentifier Byte No Description Format Cvt Byte Value Default Data #1 numberOfModules 1-Byte-A_UINT32 M 0x01 0x02 – 0xFF 0x01 #2 : #14 Application data module part number #1: : 13 Bytes- M : M 0x7E .Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: Internal Page 11 (90) REQ_UDS 0231 5.2.1.3 DID 0xF182 applicationDataIdentificationDataIdentifier REQ_UDS 0007 Table 8 – Description of DID 0xF182 applicationDataIdentificationDataIdentifier 0xF182 Name: applicationDataIdentificationDataIdentifier Byte No Description Format Cvt Byte Value Default Data #1 numberOfModules 1-Byte-A_UINT32 M 0x01 0x02 – 0xFF 0x01 #2 : #14 Application data module part number #1: : 13 Bytes- M : M 0x7E . Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 11 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0232 | 0x7E 0x20This DID shall be stored under dataset module stored in flash memory.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update | Interface: None Architecture: Hardware Platform Status: Missing interface | High Not needed | DetailsFull requirement statement: 0x7E 0x20 REQ_UDS 0232 This DID shall be stored under dataset module stored in flash memory. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0008 | 5.2.1.4 DID 0xF186 ActiveDiagnosticSessionDataIdentifierTable 9 – Description of DID 0xF186 ActiveDiagnosticSessionDataIdentifier 0xF186 Name: ActiveDiagnosticSessionDataIdentifier Byte No Description Format Cvt Byte Value Default Data #1 Diagnostic session type 1-Byte-A_UINT32 M 0x00 – 0xFF 0x01Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: 5.2.1.4 DID 0xF186 ActiveDiagnosticSessionDataIdentifier REQ_UDS 0008 Table 9 – Description of DID 0xF186 ActiveDiagnosticSessionDataIdentifier 0xF186 Name: ActiveDiagnosticSessionDataIdentifier Byte No Description Format Cvt Byte Value Default Data #1 Diagnostic session type 1-Byte-A_UINT32 M 0x00 – 0xFF 0x01 Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 11 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0009 | Internal Page 12 (90) 5.2.1.5 DID 0xF187 vehicleManufacturerSparePartNumberDataIdentifierTable 10 – Description of DID 0xF187 vehicleManufacturerSparePartNumberDataIdentifier 0xF187 Name: vehicleManufacturerSparePartNumberDataIdentifier Byte No Description Format Cvt Byte Value Default Data #1 : #13 Vehicle manufacturer sparepart number : G, M : M 0x7E : 0x7E 0x20 REQ_UDS 0233 This DID shall be stored under dataset module stored in flash memory.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update | Interface: OEM/Customer Review Interface Architecture: Hardware Platform; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: Internal Page 12 (90) 5.2.1.5 DID 0xF187 vehicleManufacturerSparePartNumberDataIdentifier REQ_UDS 0009 Table 10 – Description of DID 0xF187 vehicleManufacturerSparePartNumberDataIdentifier 0xF187 Name: vehicleManufacturerSparePartNumberDataIdentifier Byte No Description Format Cvt Byte Value Default Data #1 : #13 Vehicle manufacturer sparepart number : G, M : M 0x7E : 0x7E 0x20 REQ_UDS 0233 This DID shall be stored under dataset module stored in flash memory. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Interface view: OEM/Customer Review Interface. Architecture view: Hardware Platform; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Hardware platform support; Secure software update and flash readiness Mapped interface: OEM/Customer Review Interface Mapped architecture element: Hardware Platform; OEM/Customer Review Interface Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_UDS-0010 | 5.2.1.6 DID 0xF188 vehicleManufacturerECUSoftwareNumberDataIdentifierTable 11 – Description of DID 0xF188 vehicleManufacturerECUSoftwareNumberDataIdentifier 0xF188 Name: vehicleManufacturerECUSoftwareNumberDataIdentifier Byte Data #1 : #13 Vehicle manufacturer ECU (server) software number : M : M : 0x20 REQ_UDS 0234 5.2.1.7 DID 0xF189 vehicleManufacturerECUSoftwareVersionNumberDataIdentifier REQ_UDS 0011 Table 12 – Description of DID 0xF189 vehicleManufacturerECUSoftwareVersionNumberDataIdentifier 0xF189 Name: vehicleManufacturerECUSoftwareVersionNumberDataIdentifier Byte DataExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: 5.2.1.6 DID 0xF188 vehicleManufacturerECUSoftwareNumberDataIdentifier REQ_UDS 0010 Table 11 – Description of DID 0xF188 vehicleManufacturerECUSoftwareNumberDataIdentifier 0xF188 Name: vehicleManufacturerECUSoftwareNumberDataIdentifier Byte Data #1 : #13 Vehicle manufacturer ECU (server) software number : M : M : 0x20 REQ_UDS 0234 5.2.1.7 DID 0xF189 vehicleManufacturerECUSoftwareVersionNumberDataIdentifier REQ_UDS 0011 Table 12 – Description of DID 0xF189 vehicleManufacturerECUSoftwareVersionNumberDataIdentifier 0xF189 Name: vehicleManufacturerECUSoftwareVersionNumberDataIdentifier Byte Data Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 12 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0012 | Byte #7 Correction Byte #8 Correction Byte #9 Correction Byte #10 Correction XX.YY.ZZZZ (XX – Major version YY-Minor version ZZZZ – Extra release within XX.YY for Bug fixes, Functional updates etc) 10Bytes- A_ASCIISTR ING, min-max- length zero M : M : 0x20 REQ_UDS 0235 5.2.1.8 DID 0xF18A systemSupplierIdentifierDataIdentifier Table 13 – Description of DID 0xF18A systemSupplierIdentifierDataIdentifier 0xF18A Name: systemSupplierIdentifierDataIdentifier Byte No Description Format Cvt Byte Value Default Data To be specifie d by the Content and format to be specified by the supplier Should be M : M : 5.2.1.9 DID 0xF18B ECUManufacturingDateDataIdentifier REQ_UDS 0013 Table 14 – Description of DID 0xF18B ECUManufacturingDateDataIdentifier 0xF18B Name: ECUManufacturingDateDataIdentifier Byte Data #1 .Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: Byte #7 Correction Byte #8 Correction Byte #9 Correction Byte #10 Correction XX.YY.ZZZZ (XX – Major version YY-Minor version ZZZZ – Extra release within XX.YY for Bug fixes, Functional updates etc) 10Bytes- A_ASCIISTR ING, min-max- length zero M : M : 0x20 REQ_UDS 0235 5.2.1.8 DID 0xF18A systemSupplierIdentifierDataIdentifier REQ_UDS 0012 Table 13 – Description of DID 0xF18A systemSupplierIdentifierDataIdentifier 0xF18A Name: systemSupplierIdentifierDataIdentifier Byte No Description Format Cvt Byte Value Default Data To be specifie d by the Content and format to be specified by the supplier Should be M : M : 5.2.1.9 DID 0xF18B ECUManufacturingDateDataIdentifier REQ_UDS 0013 Table 14 – Description of DID 0xF18B ECUManufacturingDateDataIdentifier 0xF18B Name: ECUManufacturingDateDataIdentifier Byte Data #1 . Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 13 Classification: Not Applicable Mandatory level: Should Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_UDS-0014 | Internal Page 14 (90) byte #3 YY byte #4 YY byte #5 MM byte #6 MM byte #7 DD byte #8 DD 0x20, 0x30 – 0x39 5.2.1.10 DID 0xF18C ECUSerialNumberDataIdentifier Table 15 – Description of DID 0xF18C ECUSerialNumberDataIdentifier 0xF18C Name: ECUSerialNumberDataIdentifier Byte Data To be specified by the supplier.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Supplier Development and Production Hardening | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: Internal Page 14 (90) byte #3 YY byte #4 YY byte #5 MM byte #6 MM byte #7 DD byte #8 DD 0x20, 0x30 – 0x39 5.2.1.10 DID 0xF18C ECUSerialNumberDataIdentifier REQ_UDS 0014 Table 15 – Description of DID 0xF18C ECUSerialNumberDataIdentifier 0xF18C Name: ECUSerialNumberDataIdentifier Byte Data To be specified by the supplier. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Supplier Development and Production Hardening. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 14 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ-AUTO-00513 | Minimum length shall be 8 bytes and the assigned value shall be unique for every unit provided by one supplier per project.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: Minimum length shall be 8 bytes and the assigned value shall be unique for every unit provided by one supplier per project. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 14 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_UDS-0015 | 5.2.1.11 DID 0xF190 VINDataIdentifierTable 16 – Description of DID 0xF190 VINDataIdentifier 0xF190 Name: VINDataIdentifier Byte Data #1 : #17 VIN number : Byte #17 17-Bytes- M : M : 0x30 .Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: 5.2.1.11 DID 0xF190 VINDataIdentifier REQ_UDS 0015 Table 16 – Description of DID 0xF190 VINDataIdentifier 0xF190 Name: VINDataIdentifier Byte Data #1 : #17 VIN number : Byte #17 17-Bytes- M : M : 0x30 . Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 14 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0016 | 5.2.1.12 DID 0xF191 vehicleManufacturerECUHardwareNumberDataIdentifierTable 17 – Description of DID 0xF191 vehicleManufacturerECUHardwareNumberDataIdentifier 0xF191 Name: vehicleManufacturerECUHardwareNumberDataIdentifier Byte DataExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: 5.2.1.12 DID 0xF191 vehicleManufacturerECUHardwareNumberDataIdentifier REQ_UDS 0016 Table 17 – Description of DID 0xF191 vehicleManufacturerECUHardwareNumberDataIdentifier 0xF191 Name: vehicleManufacturerECUHardwareNumberDataIdentifier Byte Data Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 14 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0236 | 0x20This DID shall be stored under flash memory module in flash memory.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update | Interface: None Architecture: Hardware Platform Status: Missing interface | High Not needed | DetailsFull requirement statement: 0x20 REQ_UDS 0236 This DID shall be stored under flash memory module in flash memory. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 15 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0017 | 5.2.1.13 DID 0xF192 systemSupplierECUHardwareNumberDataIdentifierTable 18 – Description of DID 0xF192 systemSupplierECUHardwareNumberDataIdentifier 0xF192 Name: systemSupplierECUHardwareNumberDataIdentifier Byte Data To be specified by the External Supplier 5.2.1.14 DID 0xF193 systemSupplierECUHardwareVersionNumberDataIdentifier REQ_UDS 0018 Table 19 – Description of DID 0xF193 systemSupplierECUHardwareVersionNumberDataIdentifier 0xF193 Name: systemSupplierECUHardwareVersionNumberDataIdentifier Byte Data To be specified by the External Supplier 5.2.1.15 DID 0xF194 systemSupplierECUSoftwareNumberDataIdentifier REQ_UDS 0019 Table 20 – Description of DID 0xF194 systemSupplierECUSoftwareNumberDataIdentifier 0xF194 Name: systemSupplierECUSoftwareNumberDataIdentifier Byte No Description Format Cvt Byte Value Data To be specified by the External SupplierExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Supplier Development and Production Hardening | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: 5.2.1.13 DID 0xF192 systemSupplierECUHardwareNumberDataIdentifier REQ_UDS 0017 Table 18 – Description of DID 0xF192 systemSupplierECUHardwareNumberDataIdentifier 0xF192 Name: systemSupplierECUHardwareNumberDataIdentifier Byte Data To be specified by the External Supplier 5.2.1.14 DID 0xF193 systemSupplierECUHardwareVersionNumberDataIdentifier REQ_UDS 0018 Table 19 – Description of DID 0xF193 systemSupplierECUHardwareVersionNumberDataIdentifier 0xF193 Name: systemSupplierECUHardwareVersionNumberDataIdentifier Byte Data To be specified by the External Supplier 5.2.1.15 DID 0xF194 systemSupplierECUSoftwareNumberDataIdentifier REQ_UDS 0019 Table 20 – Description of DID 0xF194 systemSupplierECUSoftwareNumberDataIdentifier 0xF194 Name: systemSupplierECUSoftwareNumberDataIdentifier Byte No Description Format Cvt Byte Value Data To be specified by the External Supplier Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Supplier Development and Production Hardening. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 15 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0020 | Internal Page 16 (90) 5.2.1.16 DID 0xF195 systemSupplierECUSoftwareVersionNumberDataIdentifierTable 21 – Description of DID 0xF195 systemSupplierECUSoftwareVersionNumberDataIdentifier 0xF195 Name: systemSupplierECUSoftwareVersionNumberDataIdentifier Byte Data To be specified by the External supplier 5.2.1.17 DID 0xF196 exhaustRegulationOrTypeApprovalNumberDataIdentifier REQ_UDS 0021 Table 22 – Description of DID 0xF196 exhaustRegulationOrTypeApprovalNumberDataIdentifier 0xF196 Name: exhaustRegulationOrTypeApprovalNumberDataIdentifier Cvt: E Byte Data #1 : #10 Exhaust regulation or type approval 10-Bytes- M : M : 0000000 000 5.2.1.18 DID 0xF197 systemNameOrEngineTypeDataIdentifier REQ_UDS 0022 Table 23 – Description of DID 0xF197 systemNameOrEngineTypeDataIdentifier 0xF197 Name: systemNameOrEngineTypeDataIdentifier Byte Data #1 : #22 System name or engine type 6-to-22-Bytes- G, M : C : 0x20 .Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Supplier Development and Production Hardening | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: Internal Page 16 (90) 5.2.1.16 DID 0xF195 systemSupplierECUSoftwareVersionNumberDataIdentifier REQ_UDS 0020 Table 21 – Description of DID 0xF195 systemSupplierECUSoftwareVersionNumberDataIdentifier 0xF195 Name: systemSupplierECUSoftwareVersionNumberDataIdentifier Byte Data To be specified by the External supplier 5.2.1.17 DID 0xF196 exhaustRegulationOrTypeApprovalNumberDataIdentifier REQ_UDS 0021 Table 22 – Description of DID 0xF196 exhaustRegulationOrTypeApprovalNumberDataIdentifier 0xF196 Name: exhaustRegulationOrTypeApprovalNumberDataIdentifier Cvt: E Byte Data #1 : #10 Exhaust regulation or type approval 10-Bytes- M : M : 0000000 000 5.2.1.18 DID 0xF197 systemNameOrEngineTypeDataIdentifier REQ_UDS 0022 Table 23 – Description of DID 0xF197 systemNameOrEngineTypeDataIdentifier 0xF197 Name: systemNameOrEngineTypeDataIdentifier Byte Data #1 : #22 System name or engine type 6-to-22-Bytes- G, M : C : 0x20 . Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Supplier Development and Production Hardening. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 16 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0237 | 0x20INFO_UDS 0039 The format should follow the pattern: Appl: <Diag.family> <Diag.generation> Boot: <Diag.family> <Diag.generation>_BOOTExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control; Cybersecurity Evidence and DIA | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 0x20 REQ_UDS 0237 INFO_UDS 0039 The format should follow the pattern: Appl: <Diag.family> <Diag.generation> Boot: <Diag.family> <Diag.generation>_BOOT Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control; Cybersecurity Evidence and DIA. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 16 Classification: Not Applicable Mandatory level: Should Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0339 | Internal Page 17 (90) 5.2.1.19 DID 0xF198 SoftwareItemSemanticDataIdentifiersTable 24 – Description of DID 0xF198 SoftwareItemSemanticDataIdentifiers 0xF198 Name: SoftwareItemSemanticDataIdentifiers Byte Data #1 : #3 numberOfModules (m) 3-Byte- A_UINT32 M 0x000000 – 0xFFFFFF 00 #4 : #n+3 Data Identifier #1: : byte #n* C1 0x00, 0x20 – 0x7E : : : : : : : Data Identifier #m: : byte #q* C1 0x00, 0x20 – 0x7E *depends on the SoftwareItemSemanticDataIdentifiers length.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: Internal Page 17 (90) 5.2.1.19 DID 0xF198 SoftwareItemSemanticDataIdentifiers REQ_UDS 0339 Table 24 – Description of DID 0xF198 SoftwareItemSemanticDataIdentifiers 0xF198 Name: SoftwareItemSemanticDataIdentifiers Byte Data #1 : #3 numberOfModules (m) 3-Byte- A_UINT32 M 0x000000 – 0xFFFFFF 00 #4 : #n+3 Data Identifier #1: : byte #n* C1 0x00, 0x20 – 0x7E : : : : : : : Data Identifier #m: : byte #q* C1 0x00, 0x20 – 0x7E *depends on the SoftwareItemSemanticDataIdentifiers length. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Mapped security capability: None Mapped feature: Secure communication and freshness protection Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 17 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0340 | 5.2.1.20 DID 0xF199 SoftwareAssemblySemanticDataIdentifiersTable 25 – Description of DID 0xF199 SoftwareAssemblySemanticDataIdentifier s 0xF199 Name: SoftwareAssemblySemanticDataIdentifiers Byte Data #1 : #3 numberOfModules(m) 3-Byte- A_UINT32 M 0x000001 – 0xFFFFFF 01Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: 5.2.1.20 DID 0xF199 SoftwareAssemblySemanticDataIdentifiers REQ_UDS 0340 Table 25 – Description of DID 0xF199 SoftwareAssemblySemanticDataIdentifier s 0xF199 Name: SoftwareAssemblySemanticDataIdentifiers Byte Data #1 : #3 numberOfModules(m) 3-Byte- A_UINT32 M 0x000001 – 0xFFFFFF 01 Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Mapped security capability: None Mapped feature: Secure communication and freshness protection Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 17 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0341 | 5.2.1.21 DID 0xF19A HardwareSemanticDataIdentifiersTable 26 – Description of DID 0xF19A HardwareSemanticDataIdentifiers 0xF19A Name: HardwareSemanticDataIdentifiers Byte Data #1 : #3 numberOfModules(m) 3-Byte- A_UINT32 M 0x000001 – 0xFFFFFF 01 #4 : #n+3 HardwareSemantic Data Identifier #1: : byte #n* A_ASCIISTR ING, zero M 0x00, 0x20 – 0x7E : : : : : : : HardwareSemantic Data Identifier #m: : byte #q* A_ASCIISTR ING, zero C 0x00, 0x20 – 0x7E *depends on the SoftwareItemSemanticDataIdentifiers length.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: 5.2.1.21 DID 0xF19A HardwareSemanticDataIdentifiers REQ_UDS 0341 Table 26 – Description of DID 0xF19A HardwareSemanticDataIdentifiers 0xF19A Name: HardwareSemanticDataIdentifiers Byte Data #1 : #3 numberOfModules(m) 3-Byte- A_UINT32 M 0x000001 – 0xFFFFFF 01 #4 : #n+3 HardwareSemantic Data Identifier #1: : byte #n* A_ASCIISTR ING, zero M 0x00, 0x20 – 0x7E : : : : : : : HardwareSemantic Data Identifier #m: : byte #q* A_ASCIISTR ING, zero C 0x00, 0x20 – 0x7E *depends on the SoftwareItemSemanticDataIdentifiers length. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Mapped security capability: None Mapped feature: Secure communication and freshness protection Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 18 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0023 | Internal Page 19 (90) 5.2.1.22 DID 0xF19D ECUInstallationDateDataIdentifierTable 27 – Description of DID 0xF19D ECUInstallationDateDataIdentifier 0xF19D Name: ECUInstallationDateDataIdentifier Byte Data #1 .Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: Internal Page 19 (90) 5.2.1.22 DID 0xF19D ECUInstallationDateDataIdentifier REQ_UDS 0023 Table 27 – Description of DID 0xF19D ECUInstallationDateDataIdentifier 0xF19D Name: ECUInstallationDateDataIdentifier Byte Data #1 . Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 19 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0025 | #8 Format: “YYYYMMDD” byte #1 YY (most significant) byte #2 YY byte #3 YY byte #4 YY byte #5 MM byte #6 MM byte #7 DD byte #8 DD 8-Bytes- RING M : M : 0x2020 20202 020 5.2.1.23 DID 0xF1A5 vehicleManufacturerECUHardwareWithoutBootNumber Table 28 – Description of DID 0xF1A5 vehicleMannufacturerECUHardwareWithoutBootNumber 0xF1A5 Name: vehicleManufacturerECUHardwareWithoutBootNumber Byte No: Description Format Cvt Byte Value Default Data #1 : #13 vehicleManufactur er ECU Hardware Number Byte #2 : 13-Byte- M : M : Project 5.2.1.24 DID 0xF1A6 engineNumber REQ_UDS 0026 Table 29 – Description of DID 0xF1A6 engineNumber 0xF1A6 Name: engineNumber Byte Data #1 : #14 Engine number 14-Bytes- A_ASCIISTRING MM : 0x20 C = Applicable only for TRATON standalone engine solutionsExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: #8 Format: “YYYYMMDD” byte #1 YY (most significant) byte #2 YY byte #3 YY byte #4 YY byte #5 MM byte #6 MM byte #7 DD byte #8 DD 8-Bytes- RING M : M : 0x2020 20202 020 5.2.1.23 DID 0xF1A5 vehicleManufacturerECUHardwareWithoutBootNumber REQ_UDS 0025 Table 28 – Description of DID 0xF1A5 vehicleMannufacturerECUHardwareWithoutBootNumber 0xF1A5 Name: vehicleManufacturerECUHardwareWithoutBootNumber Byte No: Description Format Cvt Byte Value Default Data #1 : #13 vehicleManufactur er ECU Hardware Number Byte #2 : 13-Byte- M : M : Project 5.2.1.24 DID 0xF1A6 engineNumber REQ_UDS 0026 Table 29 – Description of DID 0xF1A6 engineNumber 0xF1A6 Name: engineNumber Byte Data #1 : #14 Engine number 14-Bytes- A_ASCIISTRING MM : 0x20 C = Applicable only for TRATON standalone engine solutions Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 19 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0027 | Internal Page 20 (90) 5.2.1.25 DID 0xF1A9 Lifetime ECU-runtime at software update stampThis DID shall contain a snapshot of the mandatory lifetime ECU-runtime operational data variable captured at the first power on after a software update.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: Internal Page 20 (90) 5.2.1.25 DID 0xF1A9 Lifetime ECU-runtime at software update stamp REQ_UDS 0027 This DID shall contain a snapshot of the mandatory lifetime ECU-runtime operational data variable captured at the first power on after a software update. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 20 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0028 | Table 30 – Description of DID 0xF1A9 Lifetime ECU-runtime at software update stamp 0xF1A9 Name: lifetimeECUruntimeAtSoftwareUpdateStamp Byte No Description Format Cvt Byte Value Default Data #1 : #4 Lifetime ECU- runtime at software update stamp Unit: s A_UINT32 M : M : 0xFFFFFFFF C = mandatory for TRATON Standalone and External engines 5.2.1.26 DID 0xF1AA Mileage at software update stamp REQ_UDS 0029 This DID shall report a snapshot of the mileage of the vehicle as received on CAN or other ECU-external source at the first reception of the signal with a good signal status after a software update.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0028 Table 30 – Description of DID 0xF1A9 Lifetime ECU-runtime at software update stamp 0xF1A9 Name: lifetimeECUruntimeAtSoftwareUpdateStamp Byte No Description Format Cvt Byte Value Default Data #1 : #4 Lifetime ECU- runtime at software update stamp Unit: s A_UINT32 M : M : 0xFFFFFFFF C = mandatory for TRATON Standalone and External engines 5.2.1.26 DID 0xF1AA Mileage at software update stamp REQ_UDS 0029 This DID shall report a snapshot of the mileage of the vehicle as received on CAN or other ECU-external source at the first reception of the signal with a good signal status after a software update. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 20 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0030 | Table 31 – Description of DID 0xF1AA Mileage at software update stamp ID Description 0xF1AA Name: mileageAtSoftwareUpdateStamp Byte No Description Format Cvt Byte Value Default Data #1 : #4 Mileage at software update stamp Unit: km Formula: 0,005*X 4-Bytes- A_UINT32 M : M : 0xFFFFFFFF C = Mandatory for ECUs that store Operational data and have access to Vehicle milage information.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: REQ_UDS 0030 Table 31 – Description of DID 0xF1AA Mileage at software update stamp ID Description 0xF1AA Name: mileageAtSoftwareUpdateStamp Byte No Description Format Cvt Byte Value Default Data #1 : #4 Mileage at software update stamp Unit: km Formula: 0,005*X 4-Bytes- A_UINT32 M : M : 0xFFFFFFFF C = Mandatory for ECUs that store Operational data and have access to Vehicle milage information. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Mapped security capability: None Mapped feature: Secure software update and flash readiness Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 20 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0032 | Internal Page 21 (90)Table 32 – Description of DID 0xF1AB Date at software update stamp 0xF1AB Name: dateAtSoftwareUpdateStamp Byte Data #1 .Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: Internal Page 21 (90) REQ_UDS 0032 Table 32 – Description of DID 0xF1AB Date at software update stamp 0xF1AB Name: dateAtSoftwareUpdateStamp Byte Data #1 . Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Mapped security capability: None Mapped feature: Secure software update and flash readiness Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 21 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0033 | 5.2.1.28 DID 0xF1AD activeECUSoftwareDataIdentifierTable 33 – Description of DID 0xF1AD activeECUSoftwareDataIdentifier 0xF1AD Name: activeECUSoftwareDataIdentifier Byte Data #1 : #2 Active ECU Software 2-Bytes- A_BYTEFIEL D M : M Boot loader: 0x0000 Application Software: 0x0002 No information: 0xFFFF Not applicabl e 5.2.1.29 DID 0xF1AF NodeUID REQ_UDS 0034 Table 34 – Description of DID 0xF1AF NodeUID 0xF1AF Name: NodeUID Byte Data #1 : #8 NodeUID 8-Bytes- A_BYTEFIELD M : M : 0x00 : 0x00Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: 5.2.1.28 DID 0xF1AD activeECUSoftwareDataIdentifier REQ_UDS 0033 Table 33 – Description of DID 0xF1AD activeECUSoftwareDataIdentifier 0xF1AD Name: activeECUSoftwareDataIdentifier Byte Data #1 : #2 Active ECU Software 2-Bytes- A_BYTEFIEL D M : M Boot loader: 0x0000 Application Software: 0x0002 No information: 0xFFFF Not applicabl e 5.2.1.29 DID 0xF1AF NodeUID REQ_UDS 0034 Table 34 – Description of DID 0xF1AF NodeUID 0xF1AF Name: NodeUID Byte Data #1 : #8 NodeUID 8-Bytes- A_BYTEFIELD M : M : 0x00 : 0x00 Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 21 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0036 | 5.2.1.30 DID 0xF1B9 RBACCIdentifierNumberTable 35 – Description of DID 0xF1B9 RBACCIdentifierNumber 0xF1B9 Name: RBACCIdentifierNumber Byte Data #1 : #16 RBACC Identifier Number 16-Bytes- A_BYTEFIELD M : M : 0x00 : 0x00 INFO_UDS 0006 Information on RBACC can be found in CVS151.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: 5.2.1.30 DID 0xF1B9 RBACCIdentifierNumber REQ_UDS 0036 Table 35 – Description of DID 0xF1B9 RBACCIdentifierNumber 0xF1B9 Name: RBACCIdentifierNumber Byte Data #1 : #16 RBACC Identifier Number 16-Bytes- A_BYTEFIELD M : M : 0x00 : 0x00 INFO_UDS 0006 Information on RBACC can be found in CVS151. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 22 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0037 | 5.2.1.31 DID 0xF1BA RBACCStructureVersionTable 36 – Description of DID 0xF1BA RBACCStructureVersion 0xF1BA Name: RBACCStructureVersion Byte Data #1 : #2 RBACC Structure Version 2-Bytes- A_BYTEFIELD M : M : 0x00 : 0x00 INFO_UDS 0007 Information on RBACC can be found in CVS151.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: 5.2.1.31 DID 0xF1BA RBACCStructureVersion REQ_UDS 0037 Table 36 – Description of DID 0xF1BA RBACCStructureVersion 0xF1BA Name: RBACCStructureVersion Byte Data #1 : #2 RBACC Structure Version 2-Bytes- A_BYTEFIELD M : M : 0x00 : 0x00 INFO_UDS 0007 Information on RBACC can be found in CVS151. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 22 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0038 | 5.2.1.32 DID 0xF1D1 RootCertificateIdentifierTable 37 – Description of DID 0xF1D1 RootCertificateIdentifier 0xF1D1 Name: RootCertificateIdentifier Byte DataExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Key and Certificate Handling | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: 5.2.1.32 DID 0xF1D1 RootCertificateIdentifier REQ_UDS 0038 Table 37 – Description of DID 0xF1D1 RootCertificateIdentifier 0xF1D1 Name: RootCertificateIdentifier Byte Data Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Key and Certificate Handling. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 22 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0039 | 32-Bytes A_BYTEFIEL D M : M 0x00 – 0xFF 0x20 5.2.1.33 DID 0xF1E1 vehicleManufacturerECUBootSoftwareNumberTable 38 – Description of DID 0xF1E1 vehicleManufacturerECUBootSoftwareNumber 0xF1E1 Name: vehicleManufacturerECUBootSoftwareNumber Byte No: Description Format Cvt Byte Value Default Data #1 : #13 vehicleManufacturer ECUBootSoftwareNu mber Byte #2 : 13-Byte- G, M : M : Project REQ_UDS 0238 This DID shall be stored under flash memory module in flash memory.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Secure Boot and Application State Control | Interface: None Architecture: Hardware Platform Status: Missing interface | High Not needed | DetailsFull requirement statement: 32-Bytes A_BYTEFIEL D M : M 0x00 – 0xFF 0x20 5.2.1.33 DID 0xF1E1 vehicleManufacturerECUBootSoftwareNumber REQ_UDS 0039 Table 38 – Description of DID 0xF1E1 vehicleManufacturerECUBootSoftwareNumber 0xF1E1 Name: vehicleManufacturerECUBootSoftwareNumber Byte No: Description Format Cvt Byte Value Default Data #1 : #13 vehicleManufacturer ECUBootSoftwareNu mber Byte #2 : 13-Byte- G, M : M : Project REQ_UDS 0238 This DID shall be stored under flash memory module in flash memory. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Secure Boot and Application State Control. Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 23 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0040 | 5.3 Diagnostic sessions requirementsA default diagnostic session shall be supported.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA; Diagnostic security | Interface: None Architecture: Security Services Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.3 Diagnostic sessions requirements REQ_UDS 0040 A default diagnostic session shall be supported. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA; Diagnostic security. Architecture view: Security Services. Mapped security capability: Diagnostic security Mapped feature: Diagnostic security Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 23 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0041 | The default diagnostic session is referred to as “defaultSession”.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: REQ_UDS 0041 The default diagnostic session is referred to as “defaultSession”. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 23 Classification: Reclassified as Informational Mandatory level: Informational Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ_UDS-0042 | A non-default diagnostic session referred to as “extendedDiagnosticSession” shall be supported.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA; Diagnostic security | Interface: None Architecture: Security Services Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0042 A non-default diagnostic session referred to as “extendedDiagnosticSession” shall be supported. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA; Diagnostic security. Architecture view: Security Services. Mapped security capability: Diagnostic security Mapped feature: Diagnostic security Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 23 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0043 | Diagnostic sessions not defined in this document shall be agreed with the vehicle manufacturer.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA; Diagnostic security | Interface: OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: REQ_UDS 0043 Diagnostic sessions not defined in this document shall be agreed with the vehicle manufacturer. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA; Diagnostic security. Interface view: OEM/Customer Review Interface. Architecture view: Security Services; OEM/Customer Review Interface. Mapped security capability: Diagnostic security Mapped feature: Diagnostic security Mapped interface: OEM/Customer Review Interface Mapped architecture element: Security Services; OEM/Customer Review Interface Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 23 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_UDS-0044 | Of a marked service, an execution shall be implemented for the specified session as perTable 39.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0044 Of a marked service, an execution shall be implemented for the specified session as perTable 39. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 23 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0045 | Internal Page 24 (90)Table 39 – Diagnostic service support Service according to ISO 14229-1 Addressin g mode Application Boot loader Def Def Extd Prg Extd DiagnosticSessionControl (0x10) F, P M M M M M ECUReset (0x11) F, P M M M M M SecurityAccess (0x27) - - - - - CommunicationControl (0x28) F, P - M - - M TesterPresent (0x3E) F, P M M M M M AccessTimingParameter (0x83) - - - - - Authentication (0x29) F, P M M M M M SecuredDataTransmission (0x84) P M M M M M ControlDTCSetting (0x85) F, P - M - - M LinkControl (0x87) - C - C C ReadDataByIdentifier (0x22) F, P M M M M M ReadMemoryByAddress (0x23) - - - - - ReadScalingDataByIdentifier (0x24) - - - - - ReadDataByPeriodicIdentifier (0x2A) - - - - - DynamicallyDefineDataIdentifier (0x2C) P U U - - - WriteDataByIdentifier (0x2E) P - M - M C WriteMemoryByAddress (0x3D) - - - - - ClearDiagnosticInformation (0x14) F, P M M - - - ReadDTCInformation (0x19) F, P M M - - - InputOutputControlByIdentifier (0x2F) P - C - - - RoutineControl (0x31) P M M - M M RequestDownload (0x34) P - C - C1 C1 RequestUpload (0x35) P - C - - - TransferData (0x36) P - C - M C RequestTransferExit (0x37) P - C - M C RequestFileTransfer (0x38) P - C - C1 C1 C1 = Either 0x34 or 0x38 is mandatory depending on file based or memory based ECU system.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Secure Boot and Application State Control; Secure Communication and Boundary Control; Key and Certificate Handling; Cybersecurity Evidence and DIA | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: Internal Page 24 (90) REQ_UDS 0045 Table 39 – Diagnostic service support Service according to ISO 14229-1 Addressin g mode Application Boot loader Def Def Extd Prg Extd DiagnosticSessionControl (0x10) F, P M M M M M ECUReset (0x11) F, P M M M M M SecurityAccess (0x27) - - - - - CommunicationControl (0x28) F, P - M - - M TesterPresent (0x3E) F, P M M M M M AccessTimingParameter (0x83) - - - - - Authentication (0x29) F, P M M M M M SecuredDataTransmission (0x84) P M M M M M ControlDTCSetting (0x85) F, P - M - - M LinkControl (0x87) - C - C C ReadDataByIdentifier (0x22) F, P M M M M M ReadMemoryByAddress (0x23) - - - - - ReadScalingDataByIdentifier (0x24) - - - - - ReadDataByPeriodicIdentifier (0x2A) - - - - - DynamicallyDefineDataIdentifier (0x2C) P U U - - - WriteDataByIdentifier (0x2E) P - M - M C WriteMemoryByAddress (0x3D) - - - - - ClearDiagnosticInformation (0x14) F, P M M - - - ReadDTCInformation (0x19) F, P M M - - - InputOutputControlByIdentifier (0x2F) P - C - - - RoutineControl (0x31) P M M - M M RequestDownload (0x34) P - C - C1 C1 RequestUpload (0x35) P - C - - - TransferData (0x36) P - C - M C RequestTransferExit (0x37) P - C - M C RequestFileTransfer (0x38) P - C - C1 C1 C1 = Either 0x34 or 0x38 is mandatory depending on file based or memory based ECU system. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Secure Boot and Application State Control; Secure Communication and Boundary Control; Key and Certificate Handling; Cybersecurity Evidence and DIA. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 24 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ-AUTO-00540 | Internal Page 25 (90) INFO_UDS 0038 In Table 39, bootloader sessions should only be applicable to Software updateable ECUs.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Secure Boot and Application State Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Internal Page 25 (90) INFO_UDS 0038 In Table 39, bootloader sessions should only be applicable to Software updateable ECUs. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Secure Boot and Application State Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 25 Classification: Not Applicable Mandatory level: Should Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0046 | The mapping of RoutineControl service routines to sessions shall be discussed and agreed with the vehicle manufacturer.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: REQ_UDS 0046 The mapping of RoutineControl service routines to sessions shall be discussed and agreed with the vehicle manufacturer. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Interface view: OEM/Customer Review Interface. Architecture view: Application Software; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: Application Software; OEM/Customer Review Interface Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 25 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_UDS-0047 | The server shall implement support for RBAC (Role Based Access Control) based on CVS151.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0047 The server shall implement support for RBAC (Role Based Access Control) based on CVS151. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 25 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0048 | CVS31 and CVS32 requirements preconditions per service shall be defined by the RBAC Configuration file in the ECU.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0048 CVS31 and CVS32 requirements preconditions per service shall be defined by the RBAC Configuration file in the ECU. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 25 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0049 | Diagnostics safe state is the following conditions that needs be satisfied to ensure vehicle is not in operation while performing certain diagnostics services.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: REQ_UDS 0049 Diagnostics safe state is the following conditions that needs be satisfied to ensure vehicle is not in operation while performing certain diagnostics services. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 25 Classification: Reclassified as Informational Mandatory level: Informational Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ_UDS-0050 | The conditions that shall be checked are • Vehicle speed ~ 0 • Engine speed ~ 0 (for vehicles with IC engines) • High Voltage system disengaged ( for vehicles with high Voltage battery system) • Gear Box in neutral • Parking brake engaged INFO_UDS 0008 Diagnostics safe state is not intended for ensuring the vehicle safety rather its conditions that are checked to prevent executing Diagnostics services during vehicle operation Diagnostics safe state shall be checked before executing the diagnostics services as per Table 40.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Security Logging and Event Handling; Cybersecurity Evidence and DIA | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: The conditions that shall be checked are • Vehicle speed ~ 0 • Engine speed ~ 0 (for vehicles with IC engines) • High Voltage system disengaged ( for vehicles with high Voltage battery system) • Gear Box in neutral • Parking brake engaged INFO_UDS 0008 Diagnostics safe state is not intended for ensuring the vehicle safety rather its conditions that are checked to prevent executing Diagnostics services during vehicle operation REQ_UDS 0050 Diagnostics safe state shall be checked before executing the diagnostics services as per Table 40. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Security Logging and Event Handling; Cybersecurity Evidence and DIA. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 25 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0051 | Internal Page 26 (90) Diagnostics Service Diag Safe state check Application Boot loader TransferData (0x36) MRequestFileTransfer (0x38) M - C1 = Mandatory except for going to default session C2 = Based on recommendation from Safety Team C3 = Needs to be defined at each individual routines The server implementation shall comply with the following state diagram and the following state transition descriptions (P1 and P2 flags should be seen as implementation hints).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Secure Boot and Application State Control; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA | Interface: None Architecture: Application Software Status: Missing interface | High Needed | DetailsFull requirement statement: Internal Page 26 (90) Diagnostics Service Diag Safe state check Application Boot loader TransferData (0x36) M - RequestFileTransfer (0x38) M - C1 = Mandatory except for going to default session C2 = Based on recommendation from Safety Team C3 = Needs to be defined at each individual routines REQ_UDS 0051 The server implementation shall comply with the following state diagram and the following state transition descriptions (P1 and P2 flags should be seen as implementation hints). Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Secure Boot and Application State Control; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; System behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 26 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Needed Human review status: Not needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ_UDS-0338 | Internal Page 27 (90) Figure 2 -State DiagramThe session transitions stated below shall be possible to request both physically or functionally addressed to the server, otherwise the applicable addressing method is stated for the explicit transition.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA | Interface: None Architecture: Backend and IT Systems Status: Missing interface | High Not needed | DetailsFull requirement statement: Internal Page 27 (90) Figure 2 -State Diagram REQ_UDS 0338 The session transitions stated below shall be possible to request both physically or functionally addressed to the server, otherwise the applicable addressing method is stated for the explicit transition. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 27 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0305 | INFO_UDS 0019 Description of the individual transitions as per Figure 2 -State Diagram is explained fromto REQ_UDS 0337.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: INFO_UDS 0019 Description of the individual transitions as per Figure 2 -State Diagram is explained from REQ_UDS 0305 to REQ_UDS 0337. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 27 Classification: Reclassified as Informational Mandatory level: Informational Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ_UDS-0306 | Internal Page 28 (90)2.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: Internal Page 28 (90) REQ_UDS 0306 2. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 28 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0316 | Internal Page 29 (90)12.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: Internal Page 29 (90) REQ_UDS 0316 12. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 29 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0328 | Internal Page 30 (90)24.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: Internal Page 30 (90) REQ_UDS 0328 24. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 30 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0052 | Internal Page 31 (90) 5.4 Data identifier requirementsProject specific DID shall be added to ranges defined as system supplier specific in ISO 14229- 1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: Compliance Process; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: Internal Page 31 (90) 5.4 Data identifier requirements REQ_UDS 0052 Project specific DID shall be added to ranges defined as system supplier specific in ISO 14229- 1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: Compliance Process; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: Compliance Process; OEM/Customer Review Interface Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 31 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_UDS-0053 | Table 41 lists reserved ECU DIDs/DID ranges which are not used for identification and which shall only be implemented in agreement with the vehicle manufacturer.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: OEM/Customer Review Interface Architecture: Hardware Platform; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: REQ_UDS 0053 Table 41 lists reserved ECU DIDs/DID ranges which are not used for identification and which shall only be implemented in agreement with the vehicle manufacturer. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Interface view: OEM/Customer Review Interface. Architecture view: Hardware Platform; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: OEM/Customer Review Interface Mapped architecture element: Hardware Platform; OEM/Customer Review Interface Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 31 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_UDS-0054 | These ECUs shall implement the following DIDs according to Table 42.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0054 These ECUs shall implement the following DIDs according to Table 42. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 31 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0055 | Internal Page 32 (90) 5.5 Diagnostic services requirementsThe SPRMIB shall be supported for services as specified in (ISO 14229-1).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security | Interface: None Architecture: Security Services Status: Missing interface | High Not needed | DetailsFull requirement statement: Internal Page 32 (90) 5.5 Diagnostic services requirements REQ_UDS 0055 The SPRMIB shall be supported for services as specified in (ISO 14229-1). Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security. Architecture view: Security Services. Mapped security capability: Diagnostic security Mapped feature: Diagnostic security Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 32 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0056 | Negative response codes specified in ISO 14229-1 Annex A.1 shall only be supported if explicitly specified by this specification or its normative references.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Compliance Process Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0056 Negative response codes specified in ISO 14229-1 Annex A.1 shall only be supported if explicitly specified by this specification or its normative references. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 32 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0342 | Negative response code 0x22, conditionsNotCorrect , shall be used if a service request is denied due to insufficient rights according to the RBACC check.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0342 Negative response code 0x22, conditionsNotCorrect , shall be used if a service request is denied due to insufficient rights according to the RBACC check. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 32 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0057 | 5.5.1 DiagnosticSessionControl (0x10) service 5.5.1.1 Request REQ_UDS 0239 5.5.1.1.1 Request parameter diagnosticSessionType - A DiagnosticSessionControl service request with parameter diagnosticSessionType set to ProgrammingSession shall be processed only if normal communication is currently switched off as a result of a previous call to the Communication Control service.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.1 DiagnosticSessionControl (0x10) service 5.5.1.1 Request REQ_UDS 0239 5.5.1.1.1 Request parameter diagnosticSessionType REQ_UDS 0057 A DiagnosticSessionControl service request with parameter diagnosticSessionType set to ProgrammingSession shall be processed only if normal communication is currently switched off as a result of a previous call to the Communication Control service. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 32 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00559 | The application shall respond with NRC 0x22 (conditionsNotCorrect) if communication has not been switched off.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: The application shall respond with NRC 0x22 (conditionsNotCorrect) if communication has not been switched off. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 32 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0058 | Table 43 – Service 0x10 request parameter diagnosticSessionType description Hex (bit 6-0) Description Cvt 0x01 defaultSession M 0x02 ProgrammingSession M 0x03 extendedDiagnosticSession M REQ_UDS 0059 Following an accepted request to switch to the ProgrammingSession, the application shall make all preparations to guarantee trouble-free programming operation.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0058 Table 43 – Service 0x10 request parameter diagnosticSessionType description Hex (bit 6-0) Description Cvt 0x01 defaultSession M 0x02 ProgrammingSession M 0x03 extendedDiagnosticSession M REQ_UDS 0059 Following an accepted request to switch to the ProgrammingSession, the application shall make all preparations to guarantee trouble-free programming operation. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 32 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00561 | In this process, it shall end all routines and functions that influence programming and ensure that the server checked for safe state conditions at minimal.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Software Update | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: In this process, it shall end all routines and functions that influence programming and ensure that the server checked for safe state conditions at minimal. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Software Update. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 32 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0060 | Before switching to programming session, the server shall ensure the applicable conditions as per Table 76Programming preconditions is checked to ensure the vehicle is in safe condition.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update | Interface: None Architecture: Backend and IT Systems Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0060 Before switching to programming session, the server shall ensure the applicable conditions as per Table 76 - Programming preconditions is checked to ensure the vehicle is in safe condition. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 32 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00563 | Its upto the ECU to include the conditions that are relevant for that particular ECU, but needs to be agreed with Vehicle Manufacturer.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | None | Interface: None Architecture: None Status: Missing security feature, interface, architecture | Medium Needed | DetailsFull requirement statement: Its upto the ECU to include the conditions that are relevant for that particular ECU, but needs to be agreed with Vehicle Manufacturer. Engineering expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Engineering interpretation: Traceability needs review before this requirement can be used as design evidence. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 32 Classification: Reclassified as Informational Mandatory level: Informational Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ_UDS-0061 | Internal Page 33 (90) 5.5.1.2 Positive response REQ_UDS 0240Positive response shall be sent before the actual switch in case switching to Programming session.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: Internal Page 33 (90) 5.5.1.2 Positive response REQ_UDS 0240 REQ_UDS 0061 Positive response shall be sent before the actual switch in case switching to Programming session. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 33 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0241 | 5.5.1.2.1 Response parameter diagnosticSessionTypeResponse parameter diagnosticSessionType shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA | Interface: None Architecture: Compliance Process Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.1.2.1 Response parameter diagnosticSessionType REQ_UDS 0241 Response parameter diagnosticSessionType shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA. Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 33 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0242 | 5.5.1.2.2 Response parameter sessionParameterRecordResponse parameter sessionParameterRecord shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Compliance Process Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.1.2.2 Response parameter sessionParameterRecord REQ_UDS 0242 Response parameter sessionParameterRecord shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 33 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0062 | 5.5.1.3 Negative response REQ_UDS 0243 5.5.2 ECUReset (0x11) serviceAn ECUReset shall not be executed if the vehicle safety can be compromised.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.1.3 Negative response REQ_UDS 0243 5.5.2 ECUReset (0x11) service REQ_UDS 0062 An ECUReset shall not be executed if the vehicle safety can be compromised. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 33 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0063 | ECU shall execute the reset only after sending a positive response to the ECU reset service REQ_UDS 0064 After a final positive response has been sent for ECUReset the server is not allowed to respond to any diagnostic service requests (except ECU identification) until it has restarted and been re- initialized.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security | Interface: None Architecture: Security Services Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0063 ECU shall execute the reset only after sending a positive response to the ECU reset service REQ_UDS 0064 After a final positive response has been sent for ECUReset the server is not allowed to respond to any diagnostic service requests (except ECU identification) until it has restarted and been re- initialized. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security. Architecture view: Security Services. Mapped security capability: Diagnostic security Mapped feature: Diagnostic security Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 33 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0065 | The server shall be available for ECU identification within one second after sending positive response message to an ECUReset request.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control | Interface: None Architecture: Hardware Platform Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0065 The server shall be available for ECU identification within one second after sending positive response message to an ECUReset request. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control. Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 33 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0066 | After ECU reset, ECU shall be restarted and re-initialized within 2sec.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control | Interface: None Architecture: Hardware Platform Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0066 After ECU reset, ECU shall be restarted and re-initialized within 2sec. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control. Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 33 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0067 | The maximum time it takes from the positive response is sent from the server until it responds to new requests shall be agreed with vehicle manufacturer and documented.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: REQ_UDS 0067 The maximum time it takes from the positive response is sent from the server until it responds to new requests shall be agreed with vehicle manufacturer and documented. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Interface view: OEM/Customer Review Interface. Architecture view: Backend and IT Systems; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: OEM/Customer Review Interface Mapped architecture element: Backend and IT Systems; OEM/Customer Review Interface Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 33 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_UDS-0068 | Internal Page 34 (90) 5.5.2.1 Request REQ_UDS 0244 5.5.2.1.1 Request parameter resetTypeTable 44 – Service 0x11 request parameter resetType description Hex (bit 6-0) Description Cvt 0x01 hardReset M 0x02 keyOffOnReset C C = If the server is connected to the ignition key REQ_UDS 0069 The ECUReset service with requestParameter value 0x01 (hardReset) shall simulate the power-on / start-up sequence performed after a server has been previously disconnected from its power supply (i.e.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control; Key and Certificate Handling; Key management | Interface: None Architecture: Security Services Status: Missing interface | High Not needed | DetailsFull requirement statement: Internal Page 34 (90) 5.5.2.1 Request REQ_UDS 0244 5.5.2.1.1 Request parameter resetType REQ_UDS 0068 Table 44 – Service 0x11 request parameter resetType description Hex (bit 6-0) Description Cvt 0x01 hardReset M 0x02 keyOffOnReset C C = If the server is connected to the ignition key REQ_UDS 0069 The ECUReset service with requestParameter value 0x01 (hardReset) shall simulate the power-on / start-up sequence performed after a server has been previously disconnected from its power supply (i.e. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control; Key and Certificate Handling; Key management. Architecture view: Security Services. Mapped security capability: Key management Mapped feature: Key management Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 34 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00573 | the disconnect from the battery shall not be simulated.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: the disconnect from the battery shall not be simulated. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 34 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00574 | The implementation of hardReset shall first ensure that data corruption will not occur.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Boot and Application State Control | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: The implementation of hardReset shall first ensure that data corruption will not occur. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Boot and Application State Control. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 34 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0070 | The ECUReset service with requestParameter value 0x02 (keyOffOnReset) shall simulate the turning of the ignition key off and back on and shall ensure that the values of non-volatile memory locations are preserved and the volatile memory will be initialized.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control; Key and Certificate Handling; Key management | Interface: None Architecture: Security Services Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0070 The ECUReset service with requestParameter value 0x02 (keyOffOnReset) shall simulate the turning of the ignition key off and back on and shall ensure that the values of non-volatile memory locations are preserved and the volatile memory will be initialized. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control; Key and Certificate Handling; Key management. Architecture view: Security Services. Mapped security capability: Key management Mapped feature: Key management Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 34 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0071 | The implementation of ECUReset service with requestParameter value 0x02 (keyOffOnReset) shall ensure that every server task is finished prior sending a positive response.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control; Key and Certificate Handling | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0071 The implementation of ECUReset service with requestParameter value 0x02 (keyOffOnReset) shall ensure that every server task is finished prior sending a positive response. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control; Key and Certificate Handling. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 34 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0072 | The implementation of ECUReset service with requestParameter value 0x02 (keyOffOnReset) shall ensure that the volatile memory buffered data is stored into non volatile memory prior sending a positive response.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control; Key and Certificate Handling | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0072 The implementation of ECUReset service with requestParameter value 0x02 (keyOffOnReset) shall ensure that the volatile memory buffered data is stored into non volatile memory prior sending a positive response. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control; Key and Certificate Handling. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 34 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00578 | INFO_UDS 0010 The server shall send an ECUReset positive response message after the server tasks above are finished but before the server performs the actual resetType.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: INFO_UDS 0010 The server shall send an ECUReset positive response message after the server tasks above are finished but before the server performs the actual resetType. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 34 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0073 | 5.5.2.2 Positive responseTable 45 – Service 0x11 positive response parameter description 1 ECUReset Response SID M 2 resetType MExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: 5.5.2.2 Positive response REQ_UDS 0073 Table 45 – Service 0x11 positive response parameter description 1 ECUReset Response SID M 2 resetType M Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 34 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0245 | Internal Page 35 (90) 5.5.2.2.1 Response parameter resetTypeResponse parameter resetType shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control | Interface: None Architecture: Compliance Process Status: Missing interface | High Not needed | DetailsFull requirement statement: Internal Page 35 (90) 5.5.2.2.1 Response parameter resetType REQ_UDS 0245 Response parameter resetType shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control. Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 35 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0074 | 5.5.2.3 Negative response REQ_UDS 0246 5.5.2.3.1 Supported negative response codesTable 46 – Service 0x11 negative response codes NRC Description and scenario 0x12 sub-functionNotSupported Refer to ISO 14229-1 for scenario.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: 5.5.2.3 Negative response REQ_UDS 0246 5.5.2.3.1 Supported negative response codes REQ_UDS 0074 Table 46 – Service 0x11 negative response codes NRC Description and scenario 0x12 sub-functionNotSupported Refer to ISO 14229-1 for scenario. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 35 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0075 | 5.5.3 CommunicationControl (0x28) serviceServers involved in engine start shall not process CommunicationControl service requests until 2 seconds after terminal 15 goes active.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.3 CommunicationControl (0x28) service REQ_UDS 0075 Servers involved in engine start shall not process CommunicationControl service requests until 2 seconds after terminal 15 goes active. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 35 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00583 | If a request is received before this time has passed the server shall respond with NRC 0x78 (requestCorrectlyReceived-ResponsePending) (and process the request and send a final response when 2 seconds have passed) or NRC 0x22 (conditionsNotCorrect).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: If a request is received before this time has passed the server shall respond with NRC 0x78 (requestCorrectlyReceived-ResponsePending) (and process the request and send a final response when 2 seconds have passed) or NRC 0x22 (conditionsNotCorrect). Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 35 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0076 | INFO_UDS 0011 This requirement mitigates DOS (Denial Of Service) attacksWhen receiving CommunicationControl service request, Gateway server applications shall ensure quieting down of network to ECUs without diagnostic server which are present in their sub-buses REQ_UDS 0077 Safety conditions are project specific and shall be checked before accepting a request to disable communication.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security | Interface: None Architecture: Security Services Status: Missing interface | High Not needed | DetailsFull requirement statement: INFO_UDS 0011 This requirement mitigates DOS (Denial Of Service) attacks REQ_UDS 0076 When receiving CommunicationControl service request, Gateway server applications shall ensure quieting down of network to ECUs without diagnostic server which are present in their sub-buses REQ_UDS 0077 Safety conditions are project specific and shall be checked before accepting a request to disable communication. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security. Architecture view: Security Services. Mapped security capability: Diagnostic security Mapped feature: Diagnostic security Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 35 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00585 | INFO_UDS 0013 Communication control service should not only be used to improve the bandwidth situation during flashing /parametrisation but also for inhibiting systems in vehicle (like engine start) to ensure safety.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: INFO_UDS 0013 Communication control service should not only be used to improve the bandwidth situation during flashing /parametrisation but also for inhibiting systems in vehicle (like engine start) to ensure safety. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 36 Classification: Not Applicable Mandatory level: Should Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0078 | 5.5.3.1 RequestTable 47 – Service 0x28 request parameter description 1 CommunicationControl Request SID M 2 controlType M 3 communicationType M 5.5.3.1.1 Request parameter controlType REQ_UDS 0079 Table 48 – Service 0x28 request parameter controlType description Hex (bit 6-0) Description Cvt 0x00 enableRxAndTx M 0x01 enableRxAndDisableTx M 0x40 – 0x5F vehicleManufacturerSpecific U 5.5.3.1.2 Request parameter communicationType REQ_UDS 0080 Table 49 – Service 0x28 request parameter communicationType description Bits Value (Hex) Description Cvt 0 -1 1 normalCommunicationMessages M 4 – 7 0 Disable / Enable specified communicationType M 5.5.3.2 Positive response REQ_UDS 0247 5.5.3.3 Negative response REQ_UDS 0248Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: 5.5.3.1 Request REQ_UDS 0078 Table 47 – Service 0x28 request parameter description 1 CommunicationControl Request SID M 2 controlType M 3 communicationType M 5.5.3.1.1 Request parameter controlType REQ_UDS 0079 Table 48 – Service 0x28 request parameter controlType description Hex (bit 6-0) Description Cvt 0x00 enableRxAndTx M 0x01 enableRxAndDisableTx M 0x40 – 0x5F vehicleManufacturerSpecific U 5.5.3.1.2 Request parameter communicationType REQ_UDS 0080 Table 49 – Service 0x28 request parameter communicationType description Bits Value (Hex) Description Cvt 0 -1 1 normalCommunicationMessages M 4 – 7 0 Disable / Enable specified communicationType M 5.5.3.2 Positive response REQ_UDS 0247 5.5.3.3 Negative response REQ_UDS 0248 Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 36 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0081 | Internal Page 37 (90) 5.5.4 TesterPresent (0x3E) service 5.5.4.1 General service requirementsIf the parameter suppressPosRespMsgIndicationBit = true in a functionally addressed request message, the service request shall not influence any ongoing physically addressed service request/response.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: Internal Page 37 (90) 5.5.4 TesterPresent (0x3E) service 5.5.4.1 General service requirements REQ_UDS 0081 If the parameter suppressPosRespMsgIndicationBit = true in a functionally addressed request message, the service request shall not influence any ongoing physically addressed service request/response. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 37 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00588 | INFO_UDS 0014 A functionally addressed TesterPresent may arrive at any time during another request.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: INFO_UDS 0014 A functionally addressed TesterPresent may arrive at any time during another request. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 37 Classification: Reclassified as Assumption Mandatory level: May Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ_UDS-0249 | 5.5.4.2 RequestRequest format and parameter shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Compliance Process Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.4.2 Request REQ_UDS 0249 Request format and parameter shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 37 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0250 | 5.5.4.3 Positive response5.5.4.4 Negative response REQ_UDS 0251 5.5.5 ControlDTCSetting (0x85) service REQ_UDS 0343 Servers shall reject a ControlDTCSetting service request (DTC setting type = off) with NRC 0x22 (conditionsNotCorrect) if programming preconditions are not satisfied.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.4.3 Positive response REQ_UDS 0250 5.5.4.4 Negative response REQ_UDS 0251 5.5.5 ControlDTCSetting (0x85) service REQ_UDS 0343 Servers shall reject a ControlDTCSetting service request (DTC setting type = off) with NRC 0x22 (conditionsNotCorrect) if programming preconditions are not satisfied. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 37 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0344 | The execution of this service in the application shall only impact the DTC settingdiagnostic tests for safety and degradations shall not be impacted (shall work as normal).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security | Interface: None Architecture: Security Services Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0344 The execution of this service in the application shall only impact the DTC setting - diagnostic tests for safety and degradations shall not be impacted (shall work as normal). Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security. Architecture view: Security Services. Mapped security capability: Diagnostic security Mapped feature: Diagnostic security Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 37 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0345 | 5.5.5.1 RequestRefer to ISO 14229-1 for request format.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: 5.5.5.1 Request REQ_UDS 0345 Refer to ISO 14229-1 for request format. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 37 Classification: Reclassified as Informational Mandatory level: Informational Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ_UDS-0346 | 5.5.5.1.1 Request parameter DTCSettingTypeRefer to ISO 14229-1 for request parameter DTCSettingType.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: 5.5.5.1.1 Request parameter DTCSettingType REQ_UDS 0346 Refer to ISO 14229-1 for request parameter DTCSettingType. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 37 Classification: Reclassified as Informational Mandatory level: Informational Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ_UDS-0347 | Internal Page 38 (90) 5.5.5.1.2 Request parameter DTCSettingControlOptionRecordRefer to ISO 14229-1 for request parameter DTCSettingControlOptionRecord.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: Internal Page 38 (90) 5.5.5.1.2 Request parameter DTCSettingControlOptionRecord REQ_UDS 0347 Refer to ISO 14229-1 for request parameter DTCSettingControlOptionRecord. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 38 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0348 | 5.5.5.2 Positive responseRefer to ISO 14229-1 for positive response format and parameter.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: 5.5.5.2 Positive response REQ_UDS 0348 Refer to ISO 14229-1 for positive response format and parameter. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 38 Classification: Reclassified as Informational Mandatory level: Informational Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ_UDS-0349 | 5.5.5.3 Negative responseRefer to ISO 14229-1 for negative response format and codes.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: 5.5.5.3 Negative response REQ_UDS 0349 Refer to ISO 14229-1 for negative response format and codes. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 38 Classification: Reclassified as Informational Mandatory level: Informational Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ_UDS-0082 | 5.5.6 Link Control (0x87) serviceThe server shall be able to switch baud rate within one second.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.6 Link Control (0x87) service REQ_UDS 0082 The server shall be able to switch baud rate within one second. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 38 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0083 | The boot loader shall inherit the selected baud rate if the LinkControl service request was received when the server was executing in the application.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0083 The boot loader shall inherit the selected baud rate if the LinkControl service request was received when the server was executing in the application. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 38 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0084 | Positive response shall be sent before the actual switch of the baud-rate takes place.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0084 Positive response shall be sent before the actual switch of the baud-rate takes place. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 38 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0085 | Internal Page 39 (90) 5.5.6.1 Request 5.5.6.2 Request parameter linkControlTypeTable 50 – Service 0x87 request parameter linkControlType description Byte Value Description Cvt 0x01 verifyModeTransitionWithFixedParameter M 0x03 transitionMode M 0x40-0x5F vehicleManufacturerSpecific U 5.5.6.2.1 Request parameter linkControlModeIdentifier REQ_UDS 0086 Table 51 – Service 0x87 request parameter linkControlModeIdentifier description Byte Value Description Cvt 0x11 CAN250000Baud C 0x12 CAN500000Baud C 0x13 CAN1000000Baud C C = Baud rates shall be defined by the Project representative.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Data Authenticity and Integrity Verification; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: Internal Page 39 (90) 5.5.6.1 Request 5.5.6.2 Request parameter linkControlType REQ_UDS 0085 Table 50 – Service 0x87 request parameter linkControlType description Byte Value Description Cvt 0x01 verifyModeTransitionWithFixedParameter M 0x03 transitionMode M 0x40-0x5F vehicleManufacturerSpecific U 5.5.6.2.1 Request parameter linkControlModeIdentifier REQ_UDS 0086 Table 51 – Service 0x87 request parameter linkControlModeIdentifier description Byte Value Description Cvt 0x11 CAN250000Baud C 0x12 CAN500000Baud C 0x13 CAN1000000Baud C C = Baud rates shall be defined by the Project representative. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Data Authenticity and Integrity Verification; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 39 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0087 | 5.5.6.3 Positive response REQ_UDS 0252 5.5.6.4 Negative Response REQ_UDS 0253 5.5.7 ReadDataByIdentifier (0x22) service 5.5.7.1 Request REQ_UDS 0254 If ECU supports request containing more than one data identifier it shall be documented (like in CDD, ODX etc).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.6.3 Positive response REQ_UDS 0252 5.5.6.4 Negative Response REQ_UDS 0253 5.5.7 ReadDataByIdentifier (0x22) service 5.5.7.1 Request REQ_UDS 0254 REQ_UDS 0087 If ECU supports request containing more than one data identifier it shall be documented (like in CDD, ODX etc). Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 39 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0255 | 5.5.7.1.1 Request parameter dataIdentifierDataIdentifier parameter definition shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Compliance Process Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.7.1.1 Request parameter dataIdentifier REQ_UDS 0255 DataIdentifier parameter definition shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 39 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0088 | Internal Page 40 (90)The data identifier ranges specified in Table 41 shall be followed.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: Internal Page 40 (90) REQ_UDS 0088 The data identifier ranges specified in Table 41 shall be followed. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 40 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0089 | 5.5.7.2 Positive response REQ_UDS 0256 5.5.7.3 Negative response REQ_UDS 0257 5.5.8 WriteDataByIdentifier (0x2E) serviceThe sequence of writing data records with service 0x2E WriteDataByIdentifier shall be independent of any specific order REQ_UDS 0090 The range of a requested dataRecord value has to be checked by the server if the DID is safety relevant.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.7.2 Positive response REQ_UDS 0256 5.5.7.3 Negative response REQ_UDS 0257 5.5.8 WriteDataByIdentifier (0x2E) service REQ_UDS 0089 The sequence of writing data records with service 0x2E WriteDataByIdentifier shall be independent of any specific order REQ_UDS 0090 The range of a requested dataRecord value has to be checked by the server if the DID is safety relevant. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 40 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0091 | All changed data shall be valid and stored into non-volatile memory at the latest after an ECU Reset(0x11) subfunction 0x02 requested from client.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control | Interface: None Architecture: Hardware Platform Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0091 All changed data shall be valid and stored into non-volatile memory at the latest after an ECU Reset(0x11) subfunction 0x02 requested from client. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control. Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 40 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0092 | If it is necessary to force an explicit transfer of buffered data into non-volatile memory then this shall be supported both with ECU-Reset Service subfunction 0x02 and ignition (IGN) key Off/On (power cycle).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control; Key and Certificate Handling; Key management | Interface: None Architecture: Security Services Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0092 If it is necessary to force an explicit transfer of buffered data into non-volatile memory then this shall be supported both with ECU-Reset Service subfunction 0x02 and ignition (IGN) key Off/On (power cycle). Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control; Key and Certificate Handling; Key management. Architecture view: Security Services. Mapped security capability: Key management Mapped feature: Key management Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 40 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0093 | Additional client requests which start copying RAM buffer data into non-volatile memory are not allowed.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: REQ_UDS 0093 Additional client requests which start copying RAM buffer data into non-volatile memory are not allowed. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 40 Classification: Reclassified as Informational Mandatory level: Informational Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00608 | If this action is necessary then it shall be integrated implicitly into ECU Reset (0x11) Service subfunction 0x02.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Boot and Application State Control; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: If this action is necessary then it shall be integrated implicitly into ECU Reset (0x11) Service subfunction 0x02. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Boot and Application State Control; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 40 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0258 | 5.5.8.1 RequestRequest format and parameter shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Compliance Process Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.8.1 Request REQ_UDS 0258 Request format and parameter shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 40 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0259 | 5.5.8.2 Positive responseExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: 5.5.8.2 Positive response REQ_UDS 0259 Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 40 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0260 | Internal Page 41 (90) 5.5.8.3 Negative response5.5.9 ClearDiagnosticInformation (0x14) service 5.5.9.1 Request REQ_UDS 0261 5.5.9.1.1 Request parameter groupOfDTC REQ_UDS 0262 groupOfDTC parameter definition shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: Internal Page 41 (90) 5.5.8.3 Negative response REQ_UDS 0260 5.5.9 ClearDiagnosticInformation (0x14) service 5.5.9.1 Request REQ_UDS 0261 5.5.9.1.1 Request parameter groupOfDTC REQ_UDS 0262 groupOfDTC parameter definition shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 41 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0094 | 5.5.9.2 Positive response REQ_UDS 0263 5.5.9.3 Negative response REQ_UDS 0264 5.5.10 ReadDTCInformation (0x19) service 5.5.10.1 Request REQ_UDS 0265 5.5.10.1.1 Request parameter reportType Table 52 – Service 0x19 request parameter reportType description 0x01 reportNumberOfDTCByStatusMask M 0x02 reportDTCByStatusMask M 0x03 reportDTCSnapshotIdentification M 0x04 reportDTCSnapshotRecordByDTCNumber M 0x06 reportDTCExtendedDataRecordByDTCNumber M 0x0F reportMirrorMemoryDTCByStatusMask UExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: 5.5.9.2 Positive response REQ_UDS 0263 5.5.9.3 Negative response REQ_UDS 0264 5.5.10 ReadDTCInformation (0x19) service 5.5.10.1 Request REQ_UDS 0265 5.5.10.1.1 Request parameter reportType REQ_UDS 0094 Table 52 – Service 0x19 request parameter reportType description 0x01 reportNumberOfDTCByStatusMask M 0x02 reportDTCByStatusMask M 0x03 reportDTCSnapshotIdentification M 0x04 reportDTCSnapshotRecordByDTCNumber M 0x06 reportDTCExtendedDataRecordByDTCNumber M 0x0F reportMirrorMemoryDTCByStatusMask U Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 41 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0095 | Internal Page 42 (90) 0x10 reportMirrorMemoryDTCExtendedDataRecordByDTCNumber U 0x11 reportNumberOfMirrorMemoryDTCByStatusMask U 0x12 reportNumberOfEmissionsRelatedOBDDTCByStatusMask E 0x13 reportEmissionsRelatedOBDDTCByStatusMask E 0x42 reportWWHOBDDTCByMaskRecord E 0x55 reportWWHOBDDTCWithPermanentStatus E Legislated OBD relevant ECUs have to support legislated OBD standards.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: Internal Page 42 (90) 0x10 reportMirrorMemoryDTCExtendedDataRecordByDTCNumber U 0x11 reportNumberOfMirrorMemoryDTCByStatusMask U 0x12 reportNumberOfEmissionsRelatedOBDDTCByStatusMask E 0x13 reportEmissionsRelatedOBDDTCByStatusMask E 0x42 reportWWHOBDDTCByMaskRecord E 0x55 reportWWHOBDDTCWithPermanentStatus E REQ_UDS 0095 Legislated OBD relevant ECUs have to support legislated OBD standards. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 42 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0266 | 5.5.10.1.2 Request parameter reportNumberOfDTCByStatusMaskReportNumberOfDTCByStatusMask parameter format shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Compliance Process Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.10.1.2 Request parameter reportNumberOfDTCByStatusMask REQ_UDS 0266 ReportNumberOfDTCByStatusMask parameter format shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 42 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0267 | 5.5.10.1.3 Request parameter DTCStatusMaskDTCStatusMask parameter format shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Compliance Process Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.10.1.3 Request parameter DTCStatusMask REQ_UDS 0267 DTCStatusMask parameter format shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 42 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0096 | 5.5.10.1.4 Request parameter DTCMaskRecordTable 53 – Service 0x19 request parameter DTCMaskRecord description Byte Description Cvt High Definition according to either ISO 15031-6, ISO 14229 vehicle- manufacturer-defined, SAE J1939-73 M Middle M Low M REQ_UDS 0097 It shall be mandatory to utilize SPNs & FMIs according to SAE J1939.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.10.1.4 Request parameter DTCMaskRecord REQ_UDS 0096 Table 53 – Service 0x19 request parameter DTCMaskRecord description Byte Description Cvt High Definition according to either ISO 15031-6, ISO 14229 vehicle- manufacturer-defined, SAE J1939-73 M Middle M Low M REQ_UDS 0097 It shall be mandatory to utilize SPNs & FMIs according to SAE J1939. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 42 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0268 | 5.5.10.1.5 Request parameter DTCSnapshotRecordNumberDTCSnapshotRecordNumber parameter format shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Compliance Process Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.10.1.5 Request parameter DTCSnapshotRecordNumber REQ_UDS 0268 DTCSnapshotRecordNumber parameter format shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 42 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0098 | Internal Page 43 (90) 5.5.10.1.6 Request parameter DTCExtDataRecordNumberTable 54 – Service 0x19 request parameter DTCExtDataRecordNumber description 0x00 Reserved by ISO/SAE M 0x11 ExtDataRecNum 1 M 0x14 ExtDataRecNum 4 M 0xFE All legislated OBD stored DTCExtendedData records E 0xFF All stored DTCExtendedData records M 5.5.10.1.7 Request parameter FunctionalGroupIdentifier REQ_UDS 0269 Response parameter FunctionalGroupIdentifier shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: Internal Page 43 (90) 5.5.10.1.6 Request parameter DTCExtDataRecordNumber REQ_UDS 0098 Table 54 – Service 0x19 request parameter DTCExtDataRecordNumber description 0x00 Reserved by ISO/SAE M 0x11 ExtDataRecNum 1 M 0x14 ExtDataRecNum 4 M 0xFE All legislated OBD stored DTCExtendedData records E 0xFF All stored DTCExtendedData records M 5.5.10.1.7 Request parameter FunctionalGroupIdentifier REQ_UDS 0269 Response parameter FunctionalGroupIdentifier shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 43 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0270 | 5.5.10.1.8 Request parameter DTCSeverityMaskRecordDTCSeverityMaskRecord parameter format shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Compliance Process Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.10.1.8 Request parameter DTCSeverityMaskRecord REQ_UDS 0270 DTCSeverityMaskRecord parameter format shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 43 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0271 | 5.5.10.1.9 Request parameter DTCSeverityMaskDTCSeverityMask parameter format shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Compliance Process Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.10.1.9 Request parameter DTCSeverityMask REQ_UDS 0271 DTCSeverityMask parameter format shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 43 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0272 | 5.5.10.2 Positive response5.5.10.2.1 Response parameter DTCStatusAvailabilityMask REQ_UDS 0273 Response parameter DTCStatusAvailabilityMask shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Compliance Process Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.10.2 Positive response REQ_UDS 0272 5.5.10.2.1 Response parameter DTCStatusAvailabilityMask REQ_UDS 0273 Response parameter DTCStatusAvailabilityMask shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 43 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0274 | 5.5.10.2.2 Response parameter DTCFormatIdentifierResponse parameter DTCFormatIdentifier shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Compliance Process Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.10.2.2 Response parameter DTCFormatIdentifier REQ_UDS 0274 Response parameter DTCFormatIdentifier shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 43 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0275 | 5.5.10.2.3 Response parameter DTCCountResponse parameter DTCCount shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Compliance Process Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.10.2.3 Response parameter DTCCount REQ_UDS 0275 Response parameter DTCCount shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 43 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0276 | Internal Page 44 (90) 5.5.10.2.4 Response parameter DTCAndStatusRecordResponse parameter DTCAndStatusRecord shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: Compliance Process Status: Missing interface | High Not needed | DetailsFull requirement statement: Internal Page 44 (90) 5.5.10.2.4 Response parameter DTCAndStatusRecord REQ_UDS 0276 Response parameter DTCAndStatusRecord shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 44 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0277 | 5.5.10.2.5 Response parameter DTCRecordResponse parameter DTCRecord shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Compliance Process Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.10.2.5 Response parameter DTCRecord REQ_UDS 0277 Response parameter DTCRecord shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 44 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00626 | 5.5.10.2.6 Response parameter reportDTCSnapshotRecordByDTCNumber The snapshot data sub-function (0x04) shall have positive response message data and format as specified in Table 67.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 5.5.10.2.6 Response parameter reportDTCSnapshotRecordByDTCNumber The snapshot data sub-function (0x04) shall have positive response message data and format as specified in Table 67. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 44 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0099 | Table 55 – Snapshot data sub-function (0x04) positive response message content and format Range tion #1 ReadDTCInformation Response SID = 0x59 M #2 reportType = [ reportDTCSnapshotRecordByDTCNumber ] = 0x04 M #3 : #6 DTCAndStatusRecord[] = [ Byte 1: DTCHighByte Byte 2: DTCMiddleByte Byte 3: DTCLowByte Byte 4: statusOfDTC 0xFF 0xFF 0xFF 0xFF M M M M #7 DTCSnapshotRecordNumber#1 This byte shall be set to value 0x01.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0099 Table 55 – Snapshot data sub-function (0x04) positive response message content and format Range tion #1 ReadDTCInformation Response SID = 0x59 M #2 reportType = [ reportDTCSnapshotRecordByDTCNumber ] = 0x04 M #3 : #6 DTCAndStatusRecord[] = [ Byte 1: DTCHighByte Byte 2: DTCMiddleByte Byte 3: DTCLowByte Byte 4: statusOfDTC 0xFF 0xFF 0xFF 0xFF M M M M #7 DTCSnapshotRecordNumber#1 This byte shall be set to value 0x01. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 44 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00628 | If a mechanic is working on the vehicle, the driveline shall report Not Ready and place the vehicle in the state PropulsionNotReady.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: If a mechanic is working on the vehicle, the driveline shall report Not Ready and place the vehicle in the state PropulsionNotReady. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 46 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00629 | Internal Page 49 (90) Range tion #54 ECU start-up and alive reasons Bits 0-3 (start-up reason): 0x0: Reserved 0x1: Primary wake-up (terminal 15 ON) 0x2: Secondary wake-up 0x3: Sub wake-up 1 0x4: Sub wake-up 2 0x5: Sub wake-up 3 0x6-0xE: Reserved 0xF: Not available Bits 4-7 (alive reason): 0x0: Reserved 0x1: Primary wake-up (terminal 15 ON) 0x2: Secondary wake-up 0x3: Sub wake-up 1 0x4: Sub wake-up 2 0x5: Sub wake-up 3 0x6: Stay alive 0x7-0xE: Reserved 0xF: Not available Note 1: While the reason for keeping the ECU alive may change during execution startup reason and alive reason are always identical at ECU startup.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Boot and Application State Control | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: Internal Page 49 (90) Range tion #54 ECU start-up and alive reasons Bits 0-3 (start-up reason): 0x0: Reserved 0x1: Primary wake-up (terminal 15 ON) 0x2: Secondary wake-up 0x3: Sub wake-up 1 0x4: Sub wake-up 2 0x5: Sub wake-up 3 0x6-0xE: Reserved 0xF: Not available Bits 4-7 (alive reason): 0x0: Reserved 0x1: Primary wake-up (terminal 15 ON) 0x2: Secondary wake-up 0x3: Sub wake-up 1 0x4: Sub wake-up 2 0x5: Sub wake-up 3 0x6: Stay alive 0x7-0xE: Reserved 0xF: Not available Note 1: While the reason for keeping the ECU alive may change during execution startup reason and alive reason are always identical at ECU startup. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Boot and Application State Control. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 49 Classification: Needs Manual Markdown Correction Mandatory level: May Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ-AUTO-00630 | dependent depend ent depende nt U #65+N+M- #66+N+M dataIdentifier 0x0000 – #67+N+M +P Data required by law or regulations Signal dependent depend ent depende nt C1 #68+N+M +P DTCSnapshotRecordNumber#2 (Latest Snapshot captured) 0x02 M #69+N+M +P DTCSnapshotRecordNumberOfIdentifiers#2 0x00 : 0xFF M #70+N+M +P : #70+2*(N +M+P) See specification for DTCSnapshotRecord[]#1 This latest snapshot shall contain the same type of data and format as DTCSnapshotRecord[]#1.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: dependent depend ent depende nt U #65+N+M- #66+N+M dataIdentifier 0x0000 – #67+N+M +P Data required by law or regulations Signal dependent depend ent depende nt C1 #68+N+M +P DTCSnapshotRecordNumber#2 (Latest Snapshot captured) 0x02 M #69+N+M +P DTCSnapshotRecordNumberOfIdentifiers#2 0x00 : 0xFF M #70+N+M +P : #70+2*(N +M+P) See specification for DTCSnapshotRecord[]#1 This latest snapshot shall contain the same type of data and format as DTCSnapshotRecord[]#1. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 50 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_UDS-0304 | DTCSnapshotRecordNumber#1 & DTCSnapshotRecordNumber#2 shall correspond to first time DTC happened and latest time DTC happened correspondingly.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0304 DTCSnapshotRecordNumber#1 & DTCSnapshotRecordNumber#2 shall correspond to first time DTC happened and latest time DTC happened correspondingly. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 50 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0100 | Internal Page 51 (90) 5.5.10.2.7 Response parameter DTCExtDataRecordNumberTable 56 – Service 0x19 response parameter DTCExtDataRecordNumber description 0x00 Reserved by ISO/SAE M 0x11 ExtDataRecNum 1 M 0x14 ExtDataRecNum 4 M 0xFE All legislated OBD stored DTCExtendedData records E 0xFF All stored DTCExtendedData records M 5.5.10.2.8 Response parameter DTCExtDataRecord REQ_UDS 0101 The extended data sub-function (0x06) shall have the positive response message data and format specified in Table 68.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: Internal Page 51 (90) 5.5.10.2.7 Response parameter DTCExtDataRecordNumber REQ_UDS 0100 Table 56 – Service 0x19 response parameter DTCExtDataRecordNumber description 0x00 Reserved by ISO/SAE M 0x11 ExtDataRecNum 1 M 0x14 ExtDataRecNum 4 M 0xFE All legislated OBD stored DTCExtendedData records E 0xFF All stored DTCExtendedData records M 5.5.10.2.8 Response parameter DTCExtDataRecord REQ_UDS 0101 The extended data sub-function (0x06) shall have the positive response message data and format specified in Table 68. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 51 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00633 | Table 57 – Extended data sub-function (0x06) positive response message content and format Byte Description Range Resolu tion #1 ReadDTCInformation Response SID = 0x59 M #2 reportType = reportDTCExtDataRecordByDTCNumber 0x06 M #3 : #6 DTCAndStatusRecord[] = [ DTCHighByte DTCMiddleByte DTCLowByte statusOfDTC ] M #7 DTCExtDataRecordNumber#1 This byte shall be set to value 0x11.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Table 57 – Extended data sub-function (0x06) positive response message content and format Byte Description Range Resolu tion #1 ReadDTCInformation Response SID = 0x59 M #2 reportType = reportDTCExtDataRecordByDTCNumber 0x06 M #3 : #6 DTCAndStatusRecord[] = [ DTCHighByte DTCMiddleByte DTCLowByte statusOfDTC ] M #7 DTCExtDataRecordNumber#1 This byte shall be set to value 0x11. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 51 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00634 | Internal Page 52 (90) Byte Description Range Resolu tion This byte shall be set to value 2 and is used to identify the response structure variant #9 Occurrence counter OCC, as described in section 5.7.2 [unsigned integer] 0..127 0 M #10 DTC priority 1 – Highest priority 2 - Second highest priority 3 – Lowest priority 255 – Unknown 1..3, 255 0xFF M #11..#16 Time/Date of the first DTC activation See Table 98 but without byte #7 and #8 M #17..#22 Time/Date of the latest DTC activation M #23..#26 ECU Operational hours at the first DTC activation [4-byte int, big endian] as described in section 5.7.5.2.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Cybersecurity Evidence and DIA | Interface: None Architecture: Hardware Platform Status: Missing interface | Medium Needed | DetailsFull requirement statement: Internal Page 52 (90) Byte Description Range Resolu tion This byte shall be set to value 2 and is used to identify the response structure variant #9 Occurrence counter OCC, as described in section 5.7.2 [unsigned integer] 0..127 0 M #10 DTC priority 1 – Highest priority 2 - Second highest priority 3 – Lowest priority 255 – Unknown 1..3, 255 0xFF M #11..#16 Time/Date of the first DTC activation See Table 98 but without byte #7 and #8 M #17..#22 Time/Date of the latest DTC activation M #23..#26 ECU Operational hours at the first DTC activation [4-byte int, big endian] as described in section 5.7.5.2. Engineering expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Engineering interpretation: Security view: Cybersecurity Evidence and DIA. Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 52 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Needed Human review status: Not needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00635 | For these ECUs these bytes shall contain default value 0xFF (all bytes).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: For these ECUs these bytes shall contain default value 0xFF (all bytes). Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 52 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00636 | Internal Page 53 (90) Byte Description Range Resolu tion 0: 0 m 1: 5 m (factor 5) … 4261412863: 21 307 064 315 m #35..#38 Total vehicle distance at the latest DTC activation [4-byte int, big endian] in section 5.7.4.1 Not used for TRATON External engine and marine ECUsFor these ECUs these bytes shall contain default value 0xFF (all bytes).Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Cybersecurity Evidence and DIA | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Internal Page 53 (90) Byte Description Range Resolu tion 0: 0 m 1: 5 m (factor 5) … 4261412863: 21 307 064 315 m #35..#38 Total vehicle distance at the latest DTC activation [4-byte int, big endian] in section 5.7.4.1 Not used for TRATON External engine and marine ECUsFor these ECUs these bytes shall contain default value 0xFF (all bytes). Engineering expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Engineering interpretation: Security view: Cybersecurity Evidence and DIA. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 53 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00637 | 0: 0 m 1: 5 m (factor 5) … 4261412863: 21 307 064 315 m 0xFFF FFFFF 5 m/bit 0xFF (all bytes) C #41+(2p+1) +1 DTCExtDataRecordNumber#4 This byte shall be set to value 0x14.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 0: 0 m 1: 5 m (factor 5) … 4261412863: 21 307 064 315 m 0xFFF FFFFF 5 m/bit 0xFF (all bytes) C #41+(2p+1) +1 DTCExtDataRecordNumber#4 This byte shall be set to value 0x14. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 53 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0278 | 5.5.10.2.9 Response parameter FunctionalGroupIdentifierResponse parameter FunctionalGroupIdentifier shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Compliance Process Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.10.2.9 Response parameter FunctionalGroupIdentifier REQ_UDS 0278 Response parameter FunctionalGroupIdentifier shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 53 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0279 | 5.5.10.2.10 Response parameter DTCSeverityAvailabilityMaskResponse parameter DTCSeverityAvailabilityMask shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Compliance Process Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.10.2.10 Response parameter DTCSeverityAvailabilityMask REQ_UDS 0279 Response parameter DTCSeverityAvailabilityMask shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 53 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0280 | Internal Page 54 (90) 5.5.10.2.11 Response parameter DTCAndSeverityRecordResponse parameter DTCAndSeverityRecord shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: Compliance Process Status: Missing interface | High Not needed | DetailsFull requirement statement: Internal Page 54 (90) 5.5.10.2.11 Response parameter DTCAndSeverityRecord REQ_UDS 0280 Response parameter DTCAndSeverityRecord shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 54 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0281 | 5.5.10.3 Negative response5.5.10.3.1 Supported negative response codes REQ_UDS 0282 Negative response codes shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Compliance Process Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.10.3 Negative response REQ_UDS 0281 5.5.10.3.1 Supported negative response codes REQ_UDS 0282 Negative response codes shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 54 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0102 | 5.5.11 InputOutputControlByIdentifier (0x2F) service 5.5.11.1 Request REQ_UDS 0283 5.5.11.1.1 Request parameter dataIdentifier - The data identifier ranges specified in ISO 14229-1 shall be followed.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.11 InputOutputControlByIdentifier (0x2F) service 5.5.11.1 Request REQ_UDS 0283 5.5.11.1.1 Request parameter dataIdentifier REQ_UDS 0102 The data identifier ranges specified in ISO 14229-1 shall be followed. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 54 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0103 | 5.5.11.1.2 Request parameter controlOptionRecordTable 58 – Service 0x2F request parameter controlOptionRecord description 1 inputOutputControlParameter M 2 ..Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: 5.5.11.1.2 Request parameter controlOptionRecord REQ_UDS 0103 Table 58 – Service 0x2F request parameter controlOptionRecord description 1 inputOutputControlParameter M 2 .. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 54 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0104 | 2 + (m-1) controlState byte 1 : controlState byte m C : C 5.5.11.1.3 Request parameter inputOutputControlParameterTable 59 – Service 0x2F request parameter inputOutputControlParameter description 0x00 returnControlToECU Refer to ISO 14229-1 for parameter description.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: 2 + (m-1) controlState byte 1 : controlState byte m C : C 5.5.11.1.3 Request parameter inputOutputControlParameter REQ_UDS 0104 Table 59 – Service 0x2F request parameter inputOutputControlParameter description 0x00 returnControlToECU Refer to ISO 14229-1 for parameter description. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 54 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0284 | M 5.5.11.1.4 Request parameter controlEnableMaskRecordControlEnableMaskRecord parameter format shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Compliance Process Status: Missing interface | High Not needed | DetailsFull requirement statement: M 5.5.11.1.4 Request parameter controlEnableMaskRecord REQ_UDS 0284 ControlEnableMaskRecord parameter format shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 55 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0105 | 5.5.11.2 Positive response REQ_UDS 0285 5.5.11.3 Negative response REQ_UDS 0286 5.5.12 RoutineControl (0x31) service 5.5.12.1 Request REQ_UDS 0287 5.5.12.1.1 Request parameter RoutineControlType Table 60 – Service 0x31 request parameter RoutineControlType description 0x01 startRoutine M 0x02 stopRoutine C 0x03 requestRoutineResults C C = Mandatory for routines implemented according to Method “A”.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: 5.5.11.2 Positive response REQ_UDS 0285 5.5.11.3 Negative response REQ_UDS 0286 5.5.12 RoutineControl (0x31) service 5.5.12.1 Request REQ_UDS 0287 5.5.12.1.1 Request parameter RoutineControlType REQ_UDS 0105 Table 60 – Service 0x31 request parameter RoutineControlType description 0x01 startRoutine M 0x02 stopRoutine C 0x03 requestRoutineResults C C = Mandatory for routines implemented according to Method “A”. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 55 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0106 | 5.5.12.1.2 Request parameter RoutineIdentifierRequest parameter routineIdentifier shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Compliance Process Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.12.1.2 Request parameter RoutineIdentifier REQ_UDS 0106 Request parameter routineIdentifier shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 55 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00648 | The routine IDs as listed in Table 61 are reserved by TRATON and shall not be used by the system supplier.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: The routine IDs as listed in Table 61 are reserved by TRATON and shall not be used by the system supplier. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 55 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_UDS-0107 | Internal Page 56 (90)Table 61 – Service 0x31 request parameter RoutineIdentifier description 0x02B2 0x02B3 0x02B4 ReadStatusOfDiagnosticEventCodes ReadDiagnosticEventCodesByStatus ReadEventCodeData These routine IDs are used to handle diagnostic event codes and only mandatory when these type of data are used.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Security Logging and Event Handling; Cybersecurity Evidence and DIA | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: Internal Page 56 (90) REQ_UDS 0107 Table 61 – Service 0x31 request parameter RoutineIdentifier description 0x02B2 0x02B3 0x02B4 ReadStatusOfDiagnosticEventCodes ReadDiagnosticEventCodesByStatus ReadEventCodeData These routine IDs are used to handle diagnostic event codes and only mandatory when these type of data are used. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Security Logging and Event Handling; Cybersecurity Evidence and DIA. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 56 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0288 | 5.5.12.1.3 Request parameter RoutineControlOptionRecordRequest parameter routineControlOptionRecord shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Compliance Process Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.12.1.3 Request parameter RoutineControlOptionRecord REQ_UDS 0288 Request parameter routineControlOptionRecord shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 57 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0108 | 5.5.12.2 Positive response REQ_UDS 0289 5.5.12.3 Negative response REQ_UDS 0290 5.5.13 Request Download Service (0x34)If the most recent Erase Memory routine request in the current session was made with the addressAndLengthFormatIdentifier parameter set to value 0x00 the server shall start erasing the memory area specified with the RequestDownload request.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.12.2 Positive response REQ_UDS 0289 5.5.12.3 Negative response REQ_UDS 0290 5.5.13 Request Download Service (0x34) REQ_UDS 0108 If the most recent Erase Memory routine request in the current session was made with the addressAndLengthFormatIdentifier parameter set to value 0x00 the server shall start erasing the memory area specified with the RequestDownload request. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 57 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00652 | INFO_UDS 0017 In order to satisfy stability requirements, the erasing of the boot loader may require that the old boot loader is copied into another memory area before the boot loader memory is erased, see Annex A for an implementation hint.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: INFO_UDS 0017 In order to satisfy stability requirements, the erasing of the boot loader may require that the old boot loader is copied into another memory area before the boot loader memory is erased, see Annex A for an implementation hint. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 57 Classification: Reclassified as Assumption Mandatory level: May Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ_UDS-0109 | If the most recent Erase Memory routine request in the current session was made with the addressAndLengthFormatIdentifier parameter set to value 0x00 the server shall reset the following identification DIDs to their default values: • If boot software download is requested, reset 0xF180, 0xF191 and 0xF187 to default values (some of the DIDs will be automatically erased as a consequence of erasing one or more modules).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0109 If the most recent Erase Memory routine request in the current session was made with the addressAndLengthFormatIdentifier parameter set to value 0x00 the server shall reset the following identification DIDs to their default values: • If boot software download is requested, reset 0xF180, 0xF191 and 0xF187 to default values (some of the DIDs will be automatically erased as a consequence of erasing one or more modules). Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 57 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0110 | Once the RequestDownload service has started, only services TesterPresent, ECUReset,TransferData and DiagnosticSessionControl shall be permitted until service RequestTransferExit has been called or until any of these services returns an error.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Secure Boot and Application State Control; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0110 Once the RequestDownload service has started, only services TesterPresent, ECUReset,TransferData and DiagnosticSessionControl shall be permitted until service RequestTransferExit has been called or until any of these services returns an error. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Secure Boot and Application State Control; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 57 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0111 | Internal Page 58 (90)If a non-permitted service is requested after the RequestDownload service has started and before RequestTransferExit has been called the server shall respond with NRC 0x12 (sub- functionNotSupported) and shall accept programming to proceed from the state at which it was executing before this non-permitted service was requested.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: Internal Page 58 (90) REQ_UDS 0111 If a non-permitted service is requested after the RequestDownload service has started and before RequestTransferExit has been called the server shall respond with NRC 0x12 (sub- functionNotSupported) and shall accept programming to proceed from the state at which it was executing before this non-permitted service was requested. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 58 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0112 | 5.5.13.1 RequestThe server shall support service request formatted according to Table 62.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.13.1 Request REQ_UDS 0112 The server shall support service request formatted according to Table 62. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 58 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0113 | M 5.5.13.2 Request parameter dataFormatIdentifierTable 63 – Service 0x34 request parameter dataFormatIdentifier description compressionMethod: 0x0: no compression 0x1 – 0x9: reserved for the supplier 0xA: vehicle manufacturer standard compression algorithm LZSS 0xB – 0xF: reserved for vehicle manufacturer M 0x0 – 0xFExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Supplier Development and Production Hardening | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: M 5.5.13.2 Request parameter dataFormatIdentifier REQ_UDS 0113 Table 63 – Service 0x34 request parameter dataFormatIdentifier description compressionMethod: 0x0: no compression 0x1 – 0x9: reserved for the supplier 0xA: vehicle manufacturer standard compression algorithm LZSS 0xB – 0xF: reserved for vehicle manufacturer M 0x0 – 0xF Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Supplier Development and Production Hardening. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 58 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0114 | Internal Page 59 (90) encryptingMethod: 0x0: no encryption 0x1: encryption on DSC 0x2 -0x7 : reserved for vehicle manufacturer M 0x0 – 0x1 5.5.13.3 Request parameter addressAndLengthFormatIdentifier Table 64 – Service 0x34 request parameter addressAndLengthFormatIdentifier description 7 - 4 Length (number of bytes) of the memorySize parameter M 3,4 3 - 0 Length (number of bytes) of the memoryAddress parameter M 3, 4 5.5.13.4 Positive response REQ_UDS 0115 Table 65 – Positive response parameter description #1 RequestDownload Response SID M 0x74 #2 lengthFormatIdentifier M 0x20 #3..Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: Internal Page 59 (90) encryptingMethod: 0x0: no encryption 0x1: encryption on DSC 0x2 -0x7 : reserved for vehicle manufacturer M 0x0 – 0x1 5.5.13.3 Request parameter addressAndLengthFormatIdentifier REQ_UDS 0114 Table 64 – Service 0x34 request parameter addressAndLengthFormatIdentifier description 7 - 4 Length (number of bytes) of the memorySize parameter M 3,4 3 - 0 Length (number of bytes) of the memoryAddress parameter M 3, 4 5.5.13.4 Positive response REQ_UDS 0115 Table 65 – Positive response parameter description #1 RequestDownload Response SID M 0x74 #2 lengthFormatIdentifier M 0x20 #3.. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 59 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0116 | #4 maxNumberOfBlockLength[] = [ byte #1 (MSB) byte #2 ] M M 0xFF 0xFF 5.5.13.5 Response parameter lengthFormatIdentifierTable 66 – Service 0x34 response parameter lengthFormatIdentifier description 7 - 4 Length (number of bytes) of the maxNumberOfBlockLength parameter M 0x2 3 - 0 ISO reserved.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: #4 maxNumberOfBlockLength[] = [ byte #1 (MSB) byte #2 ] M M 0xFF 0xFF 5.5.13.5 Response parameter lengthFormatIdentifier REQ_UDS 0116 Table 66 – Service 0x34 response parameter lengthFormatIdentifier description 7 - 4 Length (number of bytes) of the maxNumberOfBlockLength parameter M 0x2 3 - 0 ISO reserved. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 59 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0117 | Internal Page 60 (90) 5.5.14 RequestUpload (0x35) 5.5.14.1 RequestTable 67 – Service 0x35 request parameter description 1 RequestDownload Request SID M 2 dataFormatIdentifier M 3 addressAndLengthFormatIdentifier M 4 ..Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: Internal Page 60 (90) 5.5.14 RequestUpload (0x35) 5.5.14.1 Request REQ_UDS 0117 Table 67 – Service 0x35 request parameter description 1 RequestDownload Request SID M 2 dataFormatIdentifier M 3 addressAndLengthFormatIdentifier M 4 .. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 60 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0118 | M 5.5.14.1.1 Request parameter dataFormatIdentifierTable 68 – Service 0x35 request parameter dataFormatIdentifier description Bytes Description Cvt Values compressionMethod: 0x0: no compression 0x1 – 0x9: reserved for the supplier 0xA: vehicle manufacturer standard compression algorithm LZSS 0xB – 0xF: reserved for vehicle manufacturer M 0x0 – 0xF encryptingMethod: 0x0: no encryption 0x1: encryption on DSC 0x2 -0x7 : reserved for vehicle manufacturer M 0x0 – 0x1Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Supplier Development and Production Hardening | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: M 5.5.14.1.1 Request parameter dataFormatIdentifier REQ_UDS 0118 Table 68 – Service 0x35 request parameter dataFormatIdentifier description Bytes Description Cvt Values compressionMethod: 0x0: no compression 0x1 – 0x9: reserved for the supplier 0xA: vehicle manufacturer standard compression algorithm LZSS 0xB – 0xF: reserved for vehicle manufacturer M 0x0 – 0xF encryptingMethod: 0x0: no encryption 0x1: encryption on DSC 0x2 -0x7 : reserved for vehicle manufacturer M 0x0 – 0x1 Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Supplier Development and Production Hardening. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 60 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0119 | Internal Page 61 (90) 5.5.14.1.2 Request parameter addressAndLengthFormatIdentifierTable 69 – Service 0x35 request parameter addressAndLengthFormatIdentifier description 7 - 4 Length (number of bytes) of the memorySize parameter M 3,4 3 - 0 Length (number of bytes) of the memoryAddress parameter M 3, 4 5.5.14.1.3 Request parameter memoryAddress REQ_UDS 0291 MemoryAddress parameter definition shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: Internal Page 61 (90) 5.5.14.1.2 Request parameter addressAndLengthFormatIdentifier REQ_UDS 0119 Table 69 – Service 0x35 request parameter addressAndLengthFormatIdentifier description 7 - 4 Length (number of bytes) of the memorySize parameter M 3,4 3 - 0 Length (number of bytes) of the memoryAddress parameter M 3, 4 5.5.14.1.3 Request parameter memoryAddress REQ_UDS 0291 MemoryAddress parameter definition shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 61 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0292 | 5.5.14.1.4 Request parameter memorySizeMemorySize parameter definition shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Compliance Process Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.14.1.4 Request parameter memorySize REQ_UDS 0292 MemorySize parameter definition shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 61 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0120 | 5.5.14.2 Positive response REQ_UDS 0293 5.5.14.2.1 Response parameter lengthFormatIdentifierTable 70 – Service 0x35 response parameter lengthFormatIdentifier description 7 - 4 Length (number of bytes) of the maxNumberOfBlockLength parameter M 0x2 3 - 0 ISO reserved.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: 5.5.14.2 Positive response REQ_UDS 0293 5.5.14.2.1 Response parameter lengthFormatIdentifier REQ_UDS 0120 Table 70 – Service 0x35 response parameter lengthFormatIdentifier description 7 - 4 Length (number of bytes) of the maxNumberOfBlockLength parameter M 0x2 3 - 0 ISO reserved. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 61 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0294 | M 0 5.5.14.3 Negative responseRefer to ISO 14229-1 for negative response format and codes shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Compliance Process Status: Missing interface | High Not needed | DetailsFull requirement statement: M 0 5.5.14.3 Negative response REQ_UDS 0294 Refer to ISO 14229-1 for negative response format and codes shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 61 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0295 | 5.5.15 TransferData (0x36) service 5.5.15.1 RequestExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: 5.5.15 TransferData (0x36) service 5.5.15.1 Request REQ_UDS 0295 Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 61 Classification: Reclassified as Informational Mandatory level: Informational Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ_UDS-0296 | Internal Page 62 (90) 5.5.15.1.1 Request parameter blockSequenceCounterMemoryAddress parameter definition shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Compliance Process Status: Missing interface | High Not needed | DetailsFull requirement statement: Internal Page 62 (90) 5.5.15.1.1 Request parameter blockSequenceCounter REQ_UDS 0296 MemoryAddress parameter definition shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 62 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0297 | 5.5.15.1.2 Request parameter transferRequestParameterRecordMemorySize parameter definition shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Compliance Process Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.15.1.2 Request parameter transferRequestParameterRecord REQ_UDS 0297 MemorySize parameter definition shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 62 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0121 | 5.5.15.2 Positive response REQ_UDS 0298 5.5.15.3 Negative response REQ_UDS 0299 5.5.15.3.1 Supported negative response codes REQ_UDS 0300 5.5.16 RequestTransferExit (0x37) service 5.5.16.1 Request Table 71 – Service 0x37 request parameter description 1 RequestTransferExit Request SID M 5.5.16.1.1 Request parameter transferRequestParameterRecord REQ_UDS 0122 The transferRequestParameterRecord shall not be supported.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.15.2 Positive response REQ_UDS 0298 5.5.15.3 Negative response REQ_UDS 0299 5.5.15.3.1 Supported negative response codes REQ_UDS 0300 5.5.16 RequestTransferExit (0x37) service 5.5.16.1 Request REQ_UDS 0121 Table 71 – Service 0x37 request parameter description 1 RequestTransferExit Request SID M 5.5.16.1.1 Request parameter transferRequestParameterRecord REQ_UDS 0122 The transferRequestParameterRecord shall not be supported. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 62 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0123 | 5.5.16.2 Positive responseTable 72 – Service 0x37 positive response parameter description 1 RequestTransferExit Response SID MExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: 5.5.16.2 Positive response REQ_UDS 0123 Table 72 – Service 0x37 positive response parameter description 1 RequestTransferExit Response SID M Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 62 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0124 | Internal Page 63 (90) 5.5.16.2.1 Response parameter transferResponseParameterRecordThe transferRequestParameterRecord shall not be supported.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: Internal Page 63 (90) 5.5.16.2.1 Response parameter transferResponseParameterRecord REQ_UDS 0124 The transferRequestParameterRecord shall not be supported. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 63 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0125 | 5.5.16.3 Negative response REQ_UDS 0301 5.5.16.3.1 Supported negative response codes REQ_UDS 0302 5.5.17 SecuredDataTransmission (0x84) service This service shall be used when transmitting data in a secured mode, see CVS32.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.16.3 Negative response REQ_UDS 0301 5.5.16.3.1 Supported negative response codes REQ_UDS 0302 5.5.17 SecuredDataTransmission (0x84) service REQ_UDS 0125 This service shall be used when transmitting data in a secured mode, see CVS32. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 63 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0126 | 5.5.17.1 Request REQ_UDS 0303 5.5.17.1.1 Request message data-parameter definitionData parameter definition shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | High Not needed | DetailsFull requirement statement: 5.5.17.1 Request REQ_UDS 0303 5.5.17.1.1 Request message data-parameter definition REQ_UDS 0126 Data parameter definition shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 63 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_UDS-0127 | 5.5.17.2 Positive responsePositive response shall be as per CVS32.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.17.2 Positive response REQ_UDS 0127 Positive response shall be as per CVS32. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 63 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0128 | 5.5.17.3 Negative responseNegative response shall be as per CVS32 5.5.17.3.1 Supported negative response codes REQ_UDS 0129 Negative response format shall be as per ISO 14229-1 5.5.18 Authentication (0x29) service REQ_UDS 0130 Authentication (0x29) service shall be used for authentication of client and server.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Key and Certificate Handling | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.17.3 Negative response REQ_UDS 0128 Negative response shall be as per CVS32 5.5.17.3.1 Supported negative response codes REQ_UDS 0129 Negative response format shall be as per ISO 14229-1 5.5.18 Authentication (0x29) service REQ_UDS 0130 Authentication (0x29) service shall be used for authentication of client and server. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Key and Certificate Handling. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 63 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0133 | Internal Page 64 (90)The Authentication (0x29) service shall be implemented according to CVS31 .Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Key and Certificate Handling | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: Internal Page 64 (90) REQ_UDS 0133 The Authentication (0x29) service shall be implemented according to CVS31 . Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Key and Certificate Handling. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 64 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0134 | 5.5.18.1 RequestRefer to CVS31 .Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: 5.5.18.1 Request REQ_UDS 0134 Refer to CVS31 . Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 64 Classification: Reclassified as Informational Mandatory level: Informational Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ_UDS-0135 | 5.5.18.2 Request parameter subFunctionRefer to CVS31 .Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: 5.5.18.2 Request parameter subFunction REQ_UDS 0135 Refer to CVS31 . Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 64 Classification: Reclassified as Informational Mandatory level: Informational Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ_UDS-0136 | 5.5.18.3 Positive responseRefer to CVS31 .Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: 5.5.18.3 Positive response REQ_UDS 0136 Refer to CVS31 . Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 64 Classification: Reclassified as Informational Mandatory level: Informational Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ_UDS-0137 | 5.5.18.4 Negative response5.5.18.4.1 Supported negative response codes REQ_UDS 0138 Supported negative response codes shall be as per ISO 14229-1, especially the NRC range 0x50 – 0x5D according to Table 73.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Compliance Process Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.18.4 Negative response REQ_UDS 0137 5.5.18.4.1 Supported negative response codes REQ_UDS 0138 Supported negative response codes shall be as per ISO 14229-1, especially the NRC range 0x50 – 0x5D according to Table 73. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 64 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0139 | Internal Page 65 (90)For detailed error cases and the mapping to the corresponding NRCs the Authentication service implementation specification CVS31 shall be used.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Key and Certificate Handling | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: Internal Page 65 (90) REQ_UDS 0139 For detailed error cases and the mapping to the corresponding NRCs the Authentication service implementation specification CVS31 shall be used. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Key and Certificate Handling. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 65 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0140 | 5.5.19 RequestFileTransfer (0x38) service 5.5.19.1 Request5.5.19.2 Request Parameter modeOfOperation REQ_UDS 0141 Table 74 – Service 0x38 request parameter modeOfOperation description Byte value Description Cvt 0x00 ISO Reserved M 0x01 AddFile This value shall be used to add the file (download) defined in the filePathAndName parameter M 0x02 DeleteFile This value shall be used to delete the file defined in the filePathAndName parameter U 0x03 ReplaceFile This value shall be used to replace the file (download) defined in the filePathAndName parameter.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.5.19 RequestFileTransfer (0x38) service 5.5.19.1 Request REQ_UDS 0140 5.5.19.2 Request Parameter modeOfOperation REQ_UDS 0141 Table 74 – Service 0x38 request parameter modeOfOperation description Byte value Description Cvt 0x00 ISO Reserved M 0x01 AddFile This value shall be used to add the file (download) defined in the filePathAndName parameter M 0x02 DeleteFile This value shall be used to delete the file defined in the filePathAndName parameter U 0x03 ReplaceFile This value shall be used to replace the file (download) defined in the filePathAndName parameter. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 65 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00683 | If the file is not stored at the location the file shall be added.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: If the file is not stored at the location the file shall be added. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 65 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00684 | M 0x04 ReadFile This value shall be used to read the file (upload) at the location defined by the filePathAndName parameter.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: M 0x04 ReadFile This value shall be used to read the file (upload) at the location defined by the filePathAndName parameter. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 65 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00685 | U 0x05 ReadDir This value shall be used to read the directory defined in the filePathAndName parameter.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: U 0x05 ReadDir This value shall be used to read the directory defined in the filePathAndName parameter. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 65 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00686 | U 0x06 ResumeFile This value shall be used to resume downloading the file defined in the filePathAndName parameter at the returned filePosition indicator.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: U 0x06 ResumeFile This value shall be used to resume downloading the file defined in the filePathAndName parameter at the returned filePosition indicator. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 65 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00687 | The file specified in the filePathAndName shall already exist in the ECU’s file system.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Hardware Platform Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The file specified in the filePathAndName shall already exist in the ECU’s file system. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 65 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0142 | Internal Page 66 (90) Byte value Description Cvt 0x07 – 0xFF ISO Reserved M 5.5.19.3 Request parameter subFunctionRefer to ISO 14229-1 for parameter sub-function format shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: Internal Page 66 (90) Byte value Description Cvt 0x07 – 0xFF ISO Reserved M 5.5.19.3 Request parameter subFunction REQ_UDS 0142 Refer to ISO 14229-1 for parameter sub-function format shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 66 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0143 | 5.5.19.4 Request Parameter dataFormatIdentifierTable 75 – Service 0x38 request parameter dataFormatIdentifier description compressionMethod: 0x0: no compression 0x1 – 0x9: reserved for the supplier 0xA: vehicle manufacturer standard compression algorithm LZSS 0xB – 0xF: reserved for vehicle manufacturer M 0x0 – 0xF encryptingMethod: 0x0: no encryption 0x1: encryption on DSC 0x2 -0x7 : reserved for vehicle manufacturer M 0x0 – 0x1 5.5.19.5 Positive response REQ_UDS 0144 5.5.19.6 Negative response REQ_UDS 0145 5.5.19.7 Supported negative response codes REQ_UDS 0146 Supported negative response codes shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: 5.5.19.4 Request Parameter dataFormatIdentifier REQ_UDS 0143 Table 75 – Service 0x38 request parameter dataFormatIdentifier description compressionMethod: 0x0: no compression 0x1 – 0x9: reserved for the supplier 0xA: vehicle manufacturer standard compression algorithm LZSS 0xB – 0xF: reserved for vehicle manufacturer M 0x0 – 0xF encryptingMethod: 0x0: no encryption 0x1: encryption on DSC 0x2 -0x7 : reserved for vehicle manufacturer M 0x0 – 0x1 5.5.19.5 Positive response REQ_UDS 0144 5.5.19.6 Negative response REQ_UDS 0145 5.5.19.7 Supported negative response codes REQ_UDS 0146 Supported negative response codes shall be as per ISO 14229-1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: Application Software; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: Application Software; OEM/Customer Review Interface Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 66 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_UDS-0147 | Internal Page 67 (90)The programming preconditions shall be agreed with the vehicle manufacturer.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: Internal Page 67 (90) REQ_UDS 0147 The programming preconditions shall be agreed with the vehicle manufacturer. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior; Secure software update and flash readiness Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 67 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00691 | Preconditions to be discussed with the vehicle manufacturer shall include but not be limited to Diag safe state conditions.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Cybersecurity Evidence and DIA | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: Preconditions to be discussed with the vehicle manufacturer shall include but not be limited to Diag safe state conditions. Engineering expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Engineering interpretation: Security view: Cybersecurity Evidence and DIA. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 67 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_UDS-0148 | The decision on conditions of the programming precondition shall be based on minimum two independent sources of information.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0148 The decision on conditions of the programming precondition shall be based on minimum two independent sources of information. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 67 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0149 | If information is not available for checking a programming precondition the programming precondition shall be considered fulfilled.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0149 If information is not available for checking a programming precondition the programming precondition shall be considered fulfilled. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 67 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00694 | If the ECU received the information related to any of the conditions during the same driving cycle then it shall use that information.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Hardware Platform Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: If the ECU received the information related to any of the conditions during the same driving cycle then it shall use that information. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 67 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0150 | This routine shall be supported in Extended session of both Application and Boot.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0150 This routine shall be supported in Extended session of both Application and Boot. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 67 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0151 | 5.6.1.1 Request 5.6.1.2 Request parameter RoutineControlOptionRecordRequest parameter RoutineControlOptionRecord shall not be supported.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.6.1.1 Request 5.6.1.2 Request parameter RoutineControlOptionRecord REQ_UDS 0151 Request parameter RoutineControlOptionRecord shall not be supported. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 67 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0152 | Request parameter routineControlType with value 0x03 (requestRoutineResults) shall not be supported.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0152 Request parameter routineControlType with value 0x03 (requestRoutineResults) shall not be supported. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 67 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0153 | 5.6.1.3 Positive responseTable 76 – RoutineControl (CheckProgrammingPreconditions) positive response format #1 RoutineControl Response SID M 0x71 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) checkProgrammingPreconditions [byte#1] M 0x22 #4 routineIdentifier (LSB) checkProgrammingPreconditions [byte#2] M 0x03 #5 routineStatus (byte#1) programmingPreconditionList [byte#1] U 0x00-0xFF #5+m-1 routineStatus (byte#m) programmingPreconditionList [byte#m] U 0x00-0xFF REQ_UDS 0154 Each routineStatus byte shall represent one not satisfied precondition according to Table 18 (see definition of “Satisfied programming precondition”).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.6.1.3 Positive response REQ_UDS 0153 Table 76 – RoutineControl (CheckProgrammingPreconditions) positive response format #1 RoutineControl Response SID M 0x71 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) checkProgrammingPreconditions [byte#1] M 0x22 #4 routineIdentifier (LSB) checkProgrammingPreconditions [byte#2] M 0x03 #5 routineStatus (byte#1) programmingPreconditionList [byte#1] U 0x00-0xFF #5+m-1 routineStatus (byte#m) programmingPreconditionList [byte#m] U 0x00-0xFF REQ_UDS 0154 Each routineStatus byte shall represent one not satisfied precondition according to Table 18 (see definition of “Satisfied programming precondition”). Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 67 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0155 | Internal Page 68 (90)Which ones of the programming precondition codes in Table 18 that need to be supported shall be discussed and agreed with the vehicle manufacturer.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: Internal Page 68 (90) REQ_UDS 0155 Which ones of the programming precondition codes in Table 18 that need to be supported shall be discussed and agreed with the vehicle manufacturer. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior; Secure software update and flash readiness Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 68 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_UDS-0156 | If all preconditions are satisfied, no routineStatus byte shall be reported.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0156 If all preconditions are satisfied, no routineStatus byte shall be reported. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 68 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0157 | Programming preconditions that do not map to one of the entries in Table 77 shall be discussed with the vehicle manufacturer.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: REQ_UDS 0157 Programming preconditions that do not map to one of the entries in Table 77 shall be discussed with the vehicle manufacturer. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior; Secure software update and flash readiness Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 68 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00702 | Table 77 – Programming preconditions Hex Description Origin 0x01 Engine speed is not zero Defined by the “manufacturers software initiative” (HIS) 0x02 Engine immobilizer is not released 0x03 Transmission input speed is not zero 0x04 Transmission output speed is not zero 0x05 Vehicle speed is not zero 0x06 Closed-loop control active 0x07 Ignition system off-on required 0x08 No programming voltage 0x09 Ignition (terminal 15) is not turned on 0x0A Supply voltage too low 0x0B Temperature too high 0x0C Temperature too low ..Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Software Update | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Table 77 – Programming preconditions Hex Description Origin 0x01 Engine speed is not zero Defined by the “manufacturers software initiative” (HIS) 0x02 Engine immobilizer is not released 0x03 Transmission input speed is not zero 0x04 Transmission output speed is not zero 0x05 Vehicle speed is not zero 0x06 Closed-loop control active 0x07 Ignition system off-on required 0x08 No programming voltage 0x09 Ignition (terminal 15) is not turned on 0x0A Supply voltage too low 0x0B Temperature too high 0x0C Temperature too low .. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Software Update. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 68 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0158 | The server shall respond with a positive response code without erasing memory if the specified memory area has already been completely erased (or is writable) at the time the service is requested.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0158 The server shall respond with a positive response code without erasing memory if the specified memory area has already been completely erased (or is writable) at the time the service is requested. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 69 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00704 | INFO_UDS 0020 In order to satisfy stability requirements, the erasing of the boot loader may require that the current boot loader be copied into another non-volatile memory area before the boot loader memory is erased, see Annex A for an implementation hint.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: INFO_UDS 0020 In order to satisfy stability requirements, the erasing of the boot loader may require that the current boot loader be copied into another non-volatile memory area before the boot loader memory is erased, see Annex A for an implementation hint. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 69 Classification: Reclassified as Assumption Mandatory level: May Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ_UDS-0159 | In case the non volatile memory area is currently hosting a bootloader copy, meaning there is an ongoing bootloader update procedure, the ECU shall ensure that this memory area shall not be erased until a valid bootloader is flashed in the bootloader memory area.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Secure Boot and Application State Control | Interface: None Architecture: Hardware Platform Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0159 In case the non volatile memory area is currently hosting a bootloader copy, meaning there is an ongoing bootloader update procedure, the ECU shall ensure that this memory area shall not be erased until a valid bootloader is flashed in the bootloader memory area. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Secure Boot and Application State Control. Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 69 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0160 | Internal Page 70 (90)When the addressAndLengthFormatIdentifier parameter is set to a value > 0x00 the server shall reset the following software and data identification DIDs to their default values (see section Software and data identification): • If boot software (any part) is erased, reset 0xF180, 0xF191 and 0xF187 to default values (some of the DIDs will be automatically erased as a consequence of erasing one or more modules).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: Internal Page 70 (90) REQ_UDS 0160 When the addressAndLengthFormatIdentifier parameter is set to a value > 0x00 the server shall reset the following software and data identification DIDs to their default values (see section Software and data identification): • If boot software (any part) is erased, reset 0xF180, 0xF191 and 0xF187 to default values (some of the DIDs will be automatically erased as a consequence of erasing one or more modules). Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 70 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0161 | The erasing of memory shall not prevent the client from starting a data transfer using the TransferData (0x36) service, i.e.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control; Security Logging and Event Handling | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0161 The erasing of memory shall not prevent the client from starting a data transfer using the TransferData (0x36) service, i.e. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control; Security Logging and Event Handling. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 70 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00708 | the erasing of memory shall proceed in parallel with data transfer in case for ECUs implementing Automatic erase.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Hardware Platform Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: the erasing of memory shall proceed in parallel with data transfer in case for ECUs implementing Automatic erase. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 70 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0162 | This routine shall be supported in Programming session.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0162 This routine shall be supported in Programming session. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 70 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0163 | 5.6.2.1 RequestTable 78 – RoutineIdentifier 0xFF00 description #1 RoutineControl Request SID M 0x31 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) M 0xFF #4 routineIdentifier (LSB) M 0x00 #5 addressAndLengthFormatIdentifier (XXXXYYYYb) XXXXb = number of bytes of memorySize parameter YYYYb = number of bytes of memoryStartAddress parameter.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: 5.6.2.1 Request REQ_UDS 0163 Table 78 – RoutineIdentifier 0xFF00 description #1 RoutineControl Request SID M 0x31 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) M 0xFF #4 routineIdentifier (LSB) M 0x00 #5 addressAndLengthFormatIdentifier (XXXXYYYYb) XXXXb = number of bytes of memorySize parameter YYYYb = number of bytes of memoryStartAddress parameter. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 70 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0164 | Internal Page 71 (90)Request parameter routineControlType with value 0x03 (requestRoutineResults) shall not be supported 5.6.2.2 Request parameter addressAndLengthFormatIdentifier REQ_UDS 0165 Table 79 – Request parameter addressAndLengthFormatIdentifier values Byte Value Description Cvt 0x00 Automatic erase: Erase is performed by boot loader automatically when RequestDownload is received for each Flash sector in the module.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Secure Boot and Application State Control | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: Internal Page 71 (90) REQ_UDS 0164 Request parameter routineControlType with value 0x03 (requestRoutineResults) shall not be supported 5.6.2.2 Request parameter addressAndLengthFormatIdentifier REQ_UDS 0165 Table 79 – Request parameter addressAndLengthFormatIdentifier values Byte Value Description Cvt 0x00 Automatic erase: Erase is performed by boot loader automatically when RequestDownload is received for each Flash sector in the module. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Secure Boot and Application State Control. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 71 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00712 | 02, Module 2 (Application SW module) M 0x02 – 0xFF Physical memory range erase: Refer to ISO 14229-1 Table H1 M C = Mandatory if required to meet the performance requirements & SUV2_REQ 62 & SUV2_REQ 63 in CVS123.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Application Software Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 02, Module 2 (Application SW module) M 0x02 – 0xFF Physical memory range erase: Refer to ISO 14229-1 Table H1 M C = Mandatory if required to meet the performance requirements & SUV2_REQ 62 & SUV2_REQ 63 in CVS123. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 71 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0166 | When the addressAndLengthFormatIdentifier is set to 0x01 the following defined module to index mapping shall apply for the memoryStartAddress: 1 – Boot loader 2 – Application 3 – Application Data 4 ...Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0166 When the addressAndLengthFormatIdentifier is set to 0x01 the following defined module to index mapping shall apply for the memoryStartAddress: 1 – Boot loader 2 – Application 3 – Application Data 4 ... Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 71 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0167 | 255 – System specific 5.6.2.3 Positive responseTable 80 – RoutineControl (EraseMemory) positive response format #1 RoutineControl Response SID M 0x71 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) eraseMemory [byte#1] M 0xFF #4 routineIdentifier (LSB) eraseMemory [byte#2] M 0x00 #5 routineStatus routineResult M 0x00-0xFFExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: 255 – System specific 5.6.2.3 Positive response REQ_UDS 0167 Table 80 – RoutineControl (EraseMemory) positive response format #1 RoutineControl Response SID M 0x71 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) eraseMemory [byte#1] M 0xFF #4 routineIdentifier (LSB) eraseMemory [byte#2] M 0x00 #5 routineStatus routineResult M 0x00-0xFF Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 71 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0168 | Internal Page 72 (90)The routineResult byte values shall be as specified in Table 81.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: Internal Page 72 (90) REQ_UDS 0168 The routineResult byte values shall be as specified in Table 81. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 72 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0169 | Internal Page 74 (90) #2 routineControlType (StartRoutine) 0x01 #3 routineIdentifier (MSB) 0xFF #4 routineIdentifier (LSB) 0x00 Example #2: Negative response: server → client Table 87 – Example #2: Negative response: server → client #1 Negative Response 0x7F #2 RoutineControl Response SID 0x31 #3 conditionsNotCorrect 0x22 5.6.3 Routine 0x2401 – Software Installation The RoutineIdentifier may verify the authenticity of the received file package.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Data Authenticity and Integrity Verification | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: Internal Page 74 (90) #2 routineControlType (StartRoutine) 0x01 #3 routineIdentifier (MSB) 0xFF #4 routineIdentifier (LSB) 0x00 Example #2: Negative response: server → client Table 87 – Example #2: Negative response: server → client #1 Negative Response 0x7F #2 RoutineControl Response SID 0x31 #3 conditionsNotCorrect 0x22 5.6.3 Routine 0x2401 – Software Installation REQ_UDS 0169 The RoutineIdentifier may verify the authenticity of the received file package. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Data Authenticity and Integrity Verification. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 74 Classification: Needs Manual Markdown Correction Mandatory level: May Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0170 | If authenticity verification is valid the server shall initiate all necessary steps for installation of the received file.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA | Interface: OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: REQ_UDS 0170 If authenticity verification is valid the server shall initiate all necessary steps for installation of the received file. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA. Interface view: OEM/Customer Review Interface. Architecture view: Backend and IT Systems; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Backend and IT integration; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: Backend and IT Systems; OEM/Customer Review Interface Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 74 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_UDS-0171 | The server shall send a response to RoutineIdentifier 0x2401 Software Installation without any further inputs from the client.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0171 The server shall send a response to RoutineIdentifier 0x2401 Software Installation without any further inputs from the client. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 74 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0172 | If authenticity verification fails the server shall send the positive response with AuthenticityVerificationStatus bit 7-6 (AuthenticityStatus) set to 0x02 (Authenticity Verification Failed) and SoftwareInstallationStatus bit 7-6 (InstallationStatus) set to 0x02 (Installation Failed).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA | Interface: OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: REQ_UDS 0172 If authenticity verification fails the server shall send the positive response with AuthenticityVerificationStatus bit 7-6 (AuthenticityStatus) set to 0x02 (Authenticity Verification Failed) and SoftwareInstallationStatus bit 7-6 (InstallationStatus) set to 0x02 (Installation Failed). Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA. Interface view: OEM/Customer Review Interface. Architecture view: Backend and IT Systems; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Backend and IT integration; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: Backend and IT Systems; OEM/Customer Review Interface Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 74 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_UDS-0173 | This routine shall be supported in Programming session.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0173 This routine shall be supported in Programming session. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 74 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0174 | 5.6.3.1 RequestRequest parameter RoutineControlOptionRecord shall not be supported.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.6.3.1 Request REQ_UDS 0174 Request parameter RoutineControlOptionRecord shall not be supported. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 74 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0175 | Internal Page 75 (90) 5.6.3.2 Positive ResponsePositive responses to RoutineControl (Software Installation) service requests shall be formatted according to Table 88 and Table 89.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: Internal Page 75 (90) 5.6.3.2 Positive Response REQ_UDS 0175 Positive responses to RoutineControl (Software Installation) service requests shall be formatted according to Table 88 and Table 89. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 75 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0176 | Description Cvt Values #1 RoutineControl Request SID M 0x71 #2 routineControlType (requestRoutineResults) M 0x03 #3 routineIdentifier (MSB) M 0x24 #4 routineIdentifier (LSB) M 0x01 #5 AuthenticityVerificationStatus M 0x00 – 0xFF #6 SoftwareInstallationStatus M 0x00 – 0xFF #7 CompletionPercentage M 0x00 – 0x64 #8-#9 TimeRemaningEstimative M 0x0000 – 0xFFFF AuthenticityVerificationStatus shall be formatted according to Table 90.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: Description Cvt Values #1 RoutineControl Request SID M 0x71 #2 routineControlType (requestRoutineResults) M 0x03 #3 routineIdentifier (MSB) M 0x24 #4 routineIdentifier (LSB) M 0x01 #5 AuthenticityVerificationStatus M 0x00 – 0xFF #6 SoftwareInstallationStatus M 0x00 – 0xFF #7 CompletionPercentage M 0x00 – 0x64 #8-#9 TimeRemaningEstimative M 0x0000 – 0xFFFF REQ_UDS 0176 AuthenticityVerificationStatus shall be formatted according to Table 90. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 75 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_UDS-0177 | AuthenticityVerificationStatus bit 7-6 (AuthenticityStatus) shall remain as 0x0 (Software Authenticity Invalid) until the verification completes.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA | Interface: OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: REQ_UDS 0177 AuthenticityVerificationStatus bit 7-6 (AuthenticityStatus) shall remain as 0x0 (Software Authenticity Invalid) until the verification completes. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA. Interface view: OEM/Customer Review Interface. Architecture view: Application Software; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Application software behavior; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: Application Software; OEM/Customer Review Interface Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 75 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_UDS-0178 | If no authenticity verification will take place as part of RoutineIdentifier, the AuthenticityVerificationStatus bit 7-6 (AuthenticityStatus) shall be changed to 0x1 (Authenticity Verification Successful).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: REQ_UDS 0178 If no authenticity verification will take place as part of RoutineIdentifier, the AuthenticityVerificationStatus bit 7-6 (AuthenticityStatus) shall be changed to 0x1 (Authenticity Verification Successful). Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 75 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_UDS-0179 | Internal Page 76 (90) 0x1: Authenticity Verification Successful 0x2: Authenticity Verification Failed 5-0 Reserved Note: Shall be kept as 0x0 SoftwareInstallationStatus shall be formatted according to Table 91.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: Internal Page 76 (90) 0x1: Authenticity Verification Successful 0x2: Authenticity Verification Failed 5-0 Reserved Note: Shall be kept as 0x0 REQ_UDS 0179 SoftwareInstallationStatus shall be formatted according to Table 91. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 76 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_UDS-0180 | SoftwareInstallationStatus bit 7-6 (InstallationStatus) shall remain as 0x0 (Installation On-going) until the installation completes.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0180 SoftwareInstallationStatus bit 7-6 (InstallationStatus) shall remain as 0x0 (Installation On-going) until the installation completes. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 76 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0181 | Table 91 – SoftwareInstallationStatus Bit Bit Name Bit Values Description 7-6 InstallationStatus 0x0: Installation On-going 0x1: Installation Successful 0x2: Installation Failed 5 - 3 InstallationFailureType 0x0: No Failures 0x1 – 0x7: Project Specific 2 ResetRequired 0x0: Reset not required 0x1: Reset required 1 - 0 Reserved Note: Shall be kept as 0x0 CompletionPercentage shall inform the progress percentage of the software has been installed in the partition memory area.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: Table 91 – SoftwareInstallationStatus Bit Bit Name Bit Values Description 7-6 InstallationStatus 0x0: Installation On-going 0x1: Installation Successful 0x2: Installation Failed 5 - 3 InstallationFailureType 0x0: No Failures 0x1 – 0x7: Project Specific 2 ResetRequired 0x0: Reset not required 0x1: Reset required 1 - 0 Reserved Note: Shall be kept as 0x0 REQ_UDS 0181 CompletionPercentage shall inform the progress percentage of the software has been installed in the partition memory area. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 76 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00729 | Information shall be provided in percentage.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Information shall be provided in percentage. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 76 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0182 | TimeRemaningEstimative shall inform the time estimative to complete the installation of the file.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0182 TimeRemaningEstimative shall inform the time estimative to complete the installation of the file. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 76 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00731 | Information shall be provided in seconds.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Information shall be provided in seconds. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 76 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00732 | 5.6.3.3 Negative response INFO_UDS 0028 Whereas the result of the dependency check is returned as part of a positive response, a negative response code (NRC) shall be returned if the normal conditions according to (ISO 14229-1) (authentication, service request length, parameter range check etc) for performing the service are not correct.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Key and Certificate Handling | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 5.6.3.3 Negative response INFO_UDS 0028 Whereas the result of the dependency check is returned as part of a positive response, a negative response code (NRC) shall be returned if the normal conditions according to (ISO 14229-1) (authentication, service request length, parameter range check etc) for performing the service are not correct. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Key and Certificate Handling. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 76 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00733 | 5.6.4 Routine 0xFF01 – CheckProgrammingDependencies (check the flash programming) INFO_UDS 0029 This RoutineIdentifier value allows the client to start a consistency check of the server and should be able to execute independent from programming sequence.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 5.6.4 Routine 0xFF01 – CheckProgrammingDependencies (check the flash programming) INFO_UDS 0029 This RoutineIdentifier value allows the client to start a consistency check of the server and should be able to execute independent from programming sequence. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 76 Classification: Not Applicable Mandatory level: Should Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0183 | Internal Page 77 (90)The server shall check whether or not the individual modules are complete and compatible with one another.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | High Not needed | DetailsFull requirement statement: Internal Page 77 (90) REQ_UDS 0183 The server shall check whether or not the individual modules are complete and compatible with one another. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 77 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00735 | In addition, a check shall be made to determine whether or not the software is compatible with the hardware version (e.g., variants of sensors/actuators) and other data structures (e.g., EEPROM data).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Application Software Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: In addition, a check shall be made to determine whether or not the software is compatible with the hardware version (e.g., variants of sensors/actuators) and other data structures (e.g., EEPROM data). Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 77 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0184 | The method used to check compatibility/consistency shall be determined by the supplier in consultation with the vehicle manufacturer.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: REQ_UDS 0184 The method used to check compatibility/consistency shall be determined by the supplier in consultation with the vehicle manufacturer. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 77 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_UDS-0185 | The consistency check shall be carried out solely by the server.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0185 The consistency check shall be carried out solely by the server. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 77 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0186 | The server shall verify the authenticity and integrity of the software as a part of the consistency check.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Data Authenticity and Integrity Verification | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0186 The server shall verify the authenticity and integrity of the software as a part of the consistency check. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Data Authenticity and Integrity Verification. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 77 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0187 | The authenticity and integrity information shall be supplied to the server before the software is updated.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Data Authenticity and Integrity Verification | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0187 The authenticity and integrity information shall be supplied to the server before the software is updated. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Data Authenticity and Integrity Verification. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 77 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0188 | The authenticity and integrity check shall be carried out solely by the server.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Data Authenticity and Integrity Verification | Interface: None Architecture: Backend and IT Systems Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0188 The authenticity and integrity check shall be carried out solely by the server. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Data Authenticity and Integrity Verification. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 77 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0189 | This routine shall be supported in Programming session.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0189 This routine shall be supported in Programming session. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 77 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0190 | 5.6.4.1 RequestThe server shall support RoutineControl (CheckProgrammingDependencies) service request formatted according to Table 92.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.6.4.1 Request REQ_UDS 0190 The server shall support RoutineControl (CheckProgrammingDependencies) service request formatted according to Table 92. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 77 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0191 | Table 92 – RoutineIdentifier 0xFF01 description Byte Description Cvt Hex #1 RoutineControl Request SID M 0x31 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) M 0xFF #4 routineIdentifier (LSB) M 0x01 Request parameter routineControlType with value 0x03 (requestRoutineResults) shall not be supported.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: Table 92 – RoutineIdentifier 0xFF01 description Byte Description Cvt Hex #1 RoutineControl Request SID M 0x31 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) M 0xFF #4 routineIdentifier (LSB) M 0x01 REQ_UDS 0191 Request parameter routineControlType with value 0x03 (requestRoutineResults) shall not be supported. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 77 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0192 | Internal Page 78 (90) 5.6.4.2 Positive responsePositive responses to RoutineControl (CheckProgrammingDependencies) service requests shall be formatted according to Table 93.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: Internal Page 78 (90) 5.6.4.2 Positive response REQ_UDS 0192 Positive responses to RoutineControl (CheckProgrammingDependencies) service requests shall be formatted according to Table 93. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 78 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0193 | Table 93 – RoutineControl (CheckProgrammingDependencies) positive response format #1 RoutineControl Response SID M 0x71 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) checkProgrammingDependencies[byte#1] M 0xFF #4 routineIdentifier (LSB) checkProgrammingDependencies [byte#2] M 0x01 #5 routineStatus routineResult M 0x00-0xFF Parameter routineResult shall adopt one of the values specified in Table 94.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: Table 93 – RoutineControl (CheckProgrammingDependencies) positive response format #1 RoutineControl Response SID M 0x71 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) checkProgrammingDependencies[byte#1] M 0xFF #4 routineIdentifier (LSB) checkProgrammingDependencies [byte#2] M 0x01 #5 routineStatus routineResult M 0x00-0xFF REQ_UDS 0193 Parameter routineResult shall adopt one of the values specified in Table 94. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 78 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00746 | Table 94 – CheckProgrammingDependencies routineStatusRecord results 0x00 correctResult M 0x01 incorrectResult M 0x02 incorrectResult error SW – HW M 0x03 incorrectResult error SW – SW M 0x04 IncorrectResult One or more modules are not programmed or are incorrectly programmed M 0x05 incorrectResult One or more modules failed when verifying the authenticity and integrity of the software M 0x06 – 0xFF Reserved 5.6.4.3 Negative response INFO_UDS 0030 Whereas the result of the dependency check is returned as part of a positive response, a negative response code (NRC) shall be returned if the normal conditions according to (ISO 14229-1)(authentication, service request length, parameter range check etc) for performing the service are not correct.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Key and Certificate Handling | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Table 94 – CheckProgrammingDependencies routineStatusRecord results 0x00 correctResult M 0x01 incorrectResult M 0x02 incorrectResult error SW – HW M 0x03 incorrectResult error SW – SW M 0x04 IncorrectResult One or more modules are not programmed or are incorrectly programmed M 0x05 incorrectResult One or more modules failed when verifying the authenticity and integrity of the software M 0x06 – 0xFF Reserved 5.6.4.3 Negative response INFO_UDS 0030 Whereas the result of the dependency check is returned as part of a positive response, a negative response code (NRC) shall be returned if the normal conditions according to (ISO 14229-1)(authentication, service request length, parameter range check etc) for performing the service are not correct. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Key and Certificate Handling. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 78 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0194 | Table 96 – Positive response: server → client #1 RoutineControl Response SID 0x71 #2 routineControlType (StartRoutine) 0x01 #3 routineIdentifier byte#1 (checkProgrammingDependencies MSB) 0xFF #4 routineIdentifier byte#2 (checkProgrammingDependencies LSB) 0x01 #5 routineStatus (routineResult) 0x00 5.6.5 Routine 0xCAFE – EMP The request and response shall be implemented according to CVS33.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update | Interface: None Architecture: Backend and IT Systems Status: Missing interface | High Not needed | DetailsFull requirement statement: Table 96 – Positive response: server → client #1 RoutineControl Response SID 0x71 #2 routineControlType (StartRoutine) 0x01 #3 routineIdentifier byte#1 (checkProgrammingDependencies MSB) 0xFF #4 routineIdentifier byte#2 (checkProgrammingDependencies LSB) 0x01 #5 routineStatus (routineResult) 0x00 5.6.5 Routine 0xCAFE – EMP REQ_UDS 0194 The request and response shall be implemented according to CVS33. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration; Secure software update and flash readiness Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 79 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0195 | This routine shall be supported in all sessions of Application and Boot.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0195 This routine shall be supported in all sessions of Application and Boot. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 79 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0196 | Internal Page 80 (90) 5.7 Fault memory requirements 5.7.1 DTC status bitsTable 97 – Fault memory DTC status bits description Bit Description Cvt 0 testFailed M 1 testFailedThisOperationCycle U 2 pendingDTC M 3 confirmedDTC M 4 testNotCompletedSinceLastClear E 5 testFailedSinceLastClear U 6 testNotCompletedThisOperationCycle M 7 warningIndicatorRequested M REQ_UDS 0197 DTC status bits shall not make use of any vehicle manufacturer specific reset condition (e.g.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control | Interface: OEM/Customer Review Interface Architecture: Hardware Platform; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: Internal Page 80 (90) 5.7 Fault memory requirements 5.7.1 DTC status bits REQ_UDS 0196 Table 97 – Fault memory DTC status bits description Bit Description Cvt 0 testFailed M 1 testFailedThisOperationCycle U 2 pendingDTC M 3 confirmedDTC M 4 testNotCompletedSinceLastClear E 5 testFailedSinceLastClear U 6 testNotCompletedThisOperationCycle M 7 warningIndicatorRequested M REQ_UDS 0197 DTC status bits shall not make use of any vehicle manufacturer specific reset condition (e.g. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control. Interface view: OEM/Customer Review Interface. Architecture view: Hardware Platform; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: OEM/Customer Review Interface Mapped architecture element: Hardware Platform; OEM/Customer Review Interface Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 80 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_UDS-0198 | The occurrence counter minimum value shall be zero (0).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0198 The occurrence counter minimum value shall be zero (0). Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 80 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0199 | The occurrence counter maximum value shall be 126.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0199 The occurrence counter maximum value shall be 126. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 80 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0200 | The occurrence counter default value shall be zero (0).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0200 The occurrence counter default value shall be zero (0). Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 80 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0201 | The occurrence counter shall increment by one (1) only.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0201 The occurrence counter shall increment by one (1) only. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 80 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0202 | The occurrence counter shall increment if it’s value is not at it’s maximum value already.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0202 The occurrence counter shall increment if it’s value is not at it’s maximum value already. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 80 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0203 | The occurrence counter shall increment at a change of DTC status bits 0 testFailed and 3 confirmedDTC both from 0 to 1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0203 The occurrence counter shall increment at a change of DTC status bits 0 testFailed and 3 confirmedDTC both from 0 to 1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 80 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0204 | Internal Page 81 (90)The occurrence counter shall increment at a change of DTC status bit 0 testFailed from 0 to 1, if bit 3 confirmedDTC is 1 already.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: Internal Page 81 (90) REQ_UDS 0204 The occurrence counter shall increment at a change of DTC status bit 0 testFailed from 0 to 1, if bit 3 confirmedDTC is 1 already. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 81 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0205 | The occurrence counter shall increment at a change of DTC status bit 3 confirmedDTC from 0 to 1, if bit 0 testFailed is 1 already.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0205 The occurrence counter shall increment at a change of DTC status bit 3 confirmedDTC from 0 to 1, if bit 0 testFailed is 1 already. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 81 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0206 | The occurrence counter value 127 shall be defined as "errors with the counter".Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0206 The occurrence counter value 127 shall be defined as "errors with the counter". Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 81 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0207 | The timestamp default value shall be a 0xFF in each data.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0207 The timestamp default value shall be a 0xFF in each data. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 81 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0208 | The timestamp is presented in SAE J1939-71 format without local hour/minute offsets.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: REQ_UDS 0208 The timestamp is presented in SAE J1939-71 format without local hour/minute offsets. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 81 Classification: Reclassified as Informational Mandatory level: Informational Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ_UDS-0209 | In SAE J1939-71 section “PGN 65254 Time/Date”, the following format is specified: Table 98 – J1939-71 timestamp format Byte No Length Name Resolutio n Offset Note 1 1 byte Seconds 0.25 s/bit 0 2 1 byte Minutes 1 min/bit 0 3 1 byte Hours 1 hr/bit 0 4 1 byte Month 1 month/bit 0 Value 1 identifies January, value 2 identifies February and so on 5 1 byte Day 0.25 days/bit 0 Values 1,2,3 and 4 identifes first day of month, value 5,6,7,8 identifies second day of month and so on 6 1 byte Year 1 year/bit 1985 Value of 0 identifies year 1985, value of 1 identifes year 1986 and so on 7 1 byte Local minute offset 1 min/bit -125 Not used in DTC timestamps 8 1 byte Local hour offset 1 hr/bit -125 Not used in DTC timestampsExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: REQ_UDS 0209 In SAE J1939-71 section “PGN 65254 Time/Date”, the following format is specified: Table 98 – J1939-71 timestamp format Byte No Length Name Resolutio n Offset Note 1 1 byte Seconds 0.25 s/bit 0 2 1 byte Minutes 1 min/bit 0 3 1 byte Hours 1 hr/bit 0 4 1 byte Month 1 month/bit 0 Value 1 identifies January, value 2 identifies February and so on 5 1 byte Day 0.25 days/bit 0 Values 1,2,3 and 4 identifes first day of month, value 5,6,7,8 identifies second day of month and so on 6 1 byte Year 1 year/bit 1985 Value of 0 identifies year 1985, value of 1 identifes year 1986 and so on 7 1 byte Local minute offset 1 min/bit -125 Not used in DTC timestamps 8 1 byte Local hour offset 1 hr/bit -125 Not used in DTC timestamps Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 81 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0210 | Internal Page 82 (90) 5.7.3.1 Latest occurrenceThe latest occurrence shall be updated at a change of DTC status bits 0 (testFailed) and 3 The latest occurrence shall be updated at a change of DTC status bit 0 (testFailed) from 0 to 1, if bit 3 (confirmedDTC) is 1 already.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: Internal Page 82 (90) 5.7.3.1 Latest occurrence REQ_UDS 0210 The latest occurrence shall be updated at a change of DTC status bits 0 (testFailed) and 3 REQ_UDS 0210 The latest occurrence shall be updated at a change of DTC status bit 0 (testFailed) from 0 to 1, if bit 3 (confirmedDTC) is 1 already. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 82 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0211 | If occurrence counter is set to 1, the timestamp of the latest occurrence shall be set to 0xFF.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0211 If occurrence counter is set to 1, the timestamp of the latest occurrence shall be set to 0xFF. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 82 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0212 | 5.7.3.2 First occurrenceThe first occurrence shall be updated at the first change of DTC status bits 0 (testFailed) and 3 5.7.4 Vehicle distance at occurrence INFO_UDS 0036 The total vehicle distance at occurrence is used in DTCExtDataRecords, see section 5.5.10.2.8.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.7.3.2 First occurrence REQ_UDS 0212 The first occurrence shall be updated at the first change of DTC status bits 0 (testFailed) and 3 5.7.4 Vehicle distance at occurrence INFO_UDS 0036 The total vehicle distance at occurrence is used in DTCExtDataRecords, see section 5.5.10.2.8. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 82 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0213 | The vehicle distance shall be represented by a four byte integer, big endian, with five meter per bit (5m/bit).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0213 The vehicle distance shall be represented by a four byte integer, big endian, with five meter per bit (5m/bit). Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 82 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0214 | If all sources of vehicle distance information present no current data, the distance information shall be set to 0xFF at all bytes.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0214 If all sources of vehicle distance information present no current data, the distance information shall be set to 0xFF at all bytes. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 82 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0215 | 5.7.4.1 Latest occurrenceThe latest distance value is updated at a change of DTC status bits 0 (testFailed) and 3 REQ_UDS 0216 The latest distance value is updated at a change of DTC status bit 0 (testFailed) from 0 to 1, if bit 3 (confirmedDTC) is 1 already.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: 5.7.4.1 Latest occurrence REQ_UDS 0215 The latest distance value is updated at a change of DTC status bits 0 (testFailed) and 3 REQ_UDS 0216 The latest distance value is updated at a change of DTC status bit 0 (testFailed) from 0 to 1, if bit 3 (confirmedDTC) is 1 already. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 82 Classification: Reclassified as Informational Mandatory level: Informational Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ_UDS-0217 | 5.7.4.2 First occurrenceThe first distance value is updated at the first change of DTC status bits 0 (testFailed) and 3Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: 5.7.4.2 First occurrence REQ_UDS 0217 The first distance value is updated at the first change of DTC status bits 0 (testFailed) and 3 Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 82 Classification: Reclassified as Informational Mandatory level: Informational Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ_UDS-0218 | The operational hours are presented by a four byte integer, big endian, with , half second per bit (0,5s/bit).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: REQ_UDS 0218 The operational hours are presented by a four byte integer, big endian, with , half second per bit (0,5s/bit). Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 83 Classification: Reclassified as Informational Mandatory level: Informational Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ_UDS-0219 | If all sources of operational hours information present no current data, the operational hours information shall be set to 0xFF at all bytes.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0219 If all sources of operational hours information present no current data, the operational hours information shall be set to 0xFF at all bytes. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 83 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0220 | 5.7.5.1 Latest occurrenceThe latest operational hours value is updated at a change of DTC status bits 0 (testFailed) and 3 (confirmedDTC) both from 0 to 1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: 5.7.5.1 Latest occurrence REQ_UDS 0220 The latest operational hours value is updated at a change of DTC status bits 0 (testFailed) and 3 (confirmedDTC) both from 0 to 1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 83 Classification: Reclassified as Informational Mandatory level: Informational Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ_UDS-0221 | The latest operational hours value is updated at a change of DTC status bit 0 (testFailed) from 0 to 1, if bit 3 (confirmedDTC) is 1 already.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: REQ_UDS 0221 The latest operational hours value is updated at a change of DTC status bit 0 (testFailed) from 0 to 1, if bit 3 (confirmedDTC) is 1 already. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 83 Classification: Reclassified as Informational Mandatory level: Informational Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ_UDS-0222 | 5.7.5.2 First occurrenceThe first operational hours value is updated at the first change of DTC status bits 0 (testFailed) and 3 (confirmedDTC) both from 0 to 1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: 5.7.5.2 First occurrence REQ_UDS 0222 The first operational hours value is updated at the first change of DTC status bits 0 (testFailed) and 3 (confirmedDTC) both from 0 to 1. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 83 Classification: Reclassified as Informational Mandatory level: Informational Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ_UDS-0223 | 5.9 Performance requirements on CANThe server shall be available for complete diagnostic communication within two seconds after a power on.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security | Interface: None Architecture: Security Services Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.9 Performance requirements on CAN REQ_UDS 0223 The server shall be available for complete diagnostic communication within two seconds after a power on. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security. Architecture view: Security Services. Mapped security capability: Diagnostic security Mapped feature: Diagnostic security Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 83 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0224 | If diagnostic data is not available in time the ECU should respond with NRC 0x78 (requestCorrectlyReceived-ResponsePending) for maximum allowed time.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA; Diagnostic security | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: REQ_UDS 0224 If diagnostic data is not available in time the ECU should respond with NRC 0x78 (requestCorrectlyReceived-ResponsePending) for maximum allowed time. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA; Diagnostic security. Architecture view: Security Services. Mapped security capability: Diagnostic security Mapped feature: Diagnostic security Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 83 Classification: Not Applicable Mandatory level: Should Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00776 | for Linux based systems still running in boot, the server should indicate with DID 0xF1AD that it is running in boot.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Boot and Application State Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: for Linux based systems still running in boot, the server should indicate with DID 0xF1AD that it is running in boot. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Boot and Application State Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 83 Classification: Not Applicable Mandatory level: Should Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0225 | 5.10 Session layer performance requirementsFor P2Server, the minimum value shall be 0 ms, a maximum value shall be 50 ms.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: 5.10 Session layer performance requirements REQ_UDS 0225 For P2Server, the minimum value shall be 0 ms, a maximum value shall be 50 ms. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 83 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0226 | For P2Client, a value of 150 ms shall be used.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0226 For P2Client, a value of 150 ms shall be used. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 83 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0227 | Internal Page 84 (90)For P2*Server, the minimum value shall be 0ms, the maximum value shall be 4000ms.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | High Not needed | DetailsFull requirement statement: Internal Page 84 (90) REQ_UDS 0227 For P2*Server, the minimum value shall be 0ms, the maximum value shall be 4000ms. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 84 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0228 | For P2*Client, the value estimation given in ISO 14229-2 shall be used.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Compliance Process Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0228 For P2*Client, the value estimation given in ISO 14229-2 shall be used. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 84 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0229 | The value for P4_Server_max shall be maximum 30 seconds.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_UDS 0229 The value for P4_Server_max shall be maximum 30 seconds. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 84 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_UDS-0230 | The system supplier shall document the implemented value for P4_Server_max.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | High Not needed | DetailsFull requirement statement: REQ_UDS 0230 The system supplier shall document the implemented value for P4_Server_max. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 84 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ_UDS-0339 | Internal Page 90 (90) Annex C (informative) Change history Release date Changes 2025-12 New requirements and infos: INFO_UDS 0039: F197 structure added F198 Request and response format REQ_UDS 0340: F199 Request and response format REQ_UDS 0341: F19A Request and response format REQ_UDS 0342: NRC for RBACC check failures REQ_UDS 0343, REQ_UDS 0344, REQ_UDS 0345, REQ_UDS 0346, REQ_UDS 0347, REQ_UDS 0348, REQ_UDS 0349: Requirements, Request and response formats for the ControlDTCSetting(0x85) added.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: None Status: Missing interface, architecture | Low Not needed | DetailsFull requirement statement: Internal Page 90 (90) Annex C (informative) Change history Release date Changes 2025-12 New requirements and infos: INFO_UDS 0039: F197 structure added REQ_UDS 0339: F198 Request and response format REQ_UDS 0340: F199 Request and response format REQ_UDS 0341: F19A Request and response format REQ_UDS 0342: NRC for RBACC check failures REQ_UDS 0343, REQ_UDS 0344, REQ_UDS 0345, REQ_UDS 0346, REQ_UDS 0347, REQ_UDS 0348, REQ_UDS 0349: Requirements, Request and response formats for the ControlDTCSetting(0x85) added. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Mapped security capability: None Mapped feature: Secure communication and freshness protection Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 90 Classification: Needs Manual Markdown Correction Mandatory level: Informational Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ_UDS-0003 | Modified requirementsAdded semantic Identifier DIDs, changed the NodeUID DID to INTERNAL REQ_UDS 0034: Change in the length of NodeUID(0xF1AF) INFO_UDS 0040: Change in the retrieval method for NodeUID(0xF1AF) REQ_UDS 0036: 0xF1B9 RBACCIdentifierNumber is changed to Mandatory REQ_UDS 0037: 0xF1BA RBACCStructureVersion,bit-length changed REQ_UDS 0045: Changes for service (0x84) and (0x31) REQ_UDS 0048: Updated the document references REQ_UDS 0107: 0XCAFE and 0xFF02 are updated to Mandatory REQ_UDS 0180: Modifcations on the bit values and new bit added REQ_UDS 0193: 0x05 is changed to Mandatory 6 Normative references: Updated the referenced documents and versions Removed Requirements and infos: REQ_UDS 0045: (0x86) service removed REQ_UDS 0053, REQ_UDS 0054: Removed the reserved DID ranges and 0xF1C1 REQ_UDS 0024: 0xF19E ODXFileDataIdentifier is removed 2024-10 First issueExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: Modified requirements: REQ_UDS 0003: Added semantic Identifier DIDs, changed the NodeUID DID to INTERNAL REQ_UDS 0034: Change in the length of NodeUID(0xF1AF) INFO_UDS 0040: Change in the retrieval method for NodeUID(0xF1AF) REQ_UDS 0036: 0xF1B9 RBACCIdentifierNumber is changed to Mandatory REQ_UDS 0037: 0xF1BA RBACCStructureVersion,bit-length changed REQ_UDS 0045: Changes for service (0x84) and (0x31) REQ_UDS 0048: Updated the document references REQ_UDS 0107: 0XCAFE and 0xFF02 are updated to Mandatory REQ_UDS 0180: Modifcations on the bit values and new bit added REQ_UDS 0193: 0x05 is changed to Mandatory 6 Normative references: Updated the referenced documents and versions Removed Requirements and infos: REQ_UDS 0045: (0x86) service removed REQ_UDS 0053, REQ_UDS 0054: Removed the reserved DID ranges and 0xF1C1 REQ_UDS 0024: 0xF19E ODXFileDataIdentifier is removed 2024-10 First issue Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Secure Communication and Boundary Control. Mapped security capability: None Mapped feature: Secure communication and freshness protection Mapped interface: None Mapped architecture element: None Source PDF: CVS124.pdf Source Markdown: converted/markdown-cleaned/CVS124.md Page reference: page 90 Classification: Reclassified as Informational Mandatory level: Informational Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00785 | RBAC for diagnostics Foreword This Commercial Vehicle Standard (“CVS151”) contains requirement specifications for TRATON Group and may be referred to by any of its commercial vehicle Affiliates.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: RBAC for diagnostics Foreword This Commercial Vehicle Standard (“CVS151”) contains requirement specifications for TRATON Group and may be referred to by any of its commercial vehicle Affiliates. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 1 Classification: Reclassified as Assumption Mandatory level: May Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00786 | Any review of this CVS151 shall only be done in agreement with the involved TRATON Group commercial vehicle Affiliates stated in the table below under section “Technical responsibility”.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Compliance Process Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Any review of this CVS151 shall only be done in agreement with the involved TRATON Group commercial vehicle Affiliates stated in the table below under section “Technical responsibility”. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 1 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00787 | The User shall apply the latest version of this CVS151.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The User shall apply the latest version of this CVS151. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 1 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00788 | Page 3 1 Scope Concepts such as secure-update (CVS37) requires Role Based Access Control (RBAC) for diagnostics (UDS).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Software Update; Cybersecurity Evidence and DIA; Diagnostic security | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Page 3 1 Scope Concepts such as secure-update (CVS37) requires Role Based Access Control (RBAC) for diagnostics (UDS). Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Software Update; Cybersecurity Evidence and DIA; Diagnostic security. Architecture view: Security Services. Mapped security capability: Diagnostic security Mapped feature: Diagnostic security Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 3 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00789 | RBAC_INFO 2 Before a client can execute diagnostics services that are under RBAC, the client must perform some type of authorization procedure towards the server/ECU.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA | Interface: None Architecture: Hardware Platform Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_INFO 2 Before a client can execute diagnostics services that are under RBAC, the client must perform some type of authorization procedure towards the server/ECU. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA. Architecture view: Hardware Platform. Mapped security capability: None Mapped feature: Hardware platform support Mapped interface: None Mapped architecture element: Hardware Platform Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 4 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00790 | RBAC_REQ 1 Each RBACC shall only contain one role-configuration per each supported role.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_REQ 1 Each RBACC shall only contain one role-configuration per each supported role. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 4 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00791 | RBAC_REQ 2 If conflicting/overlapping rules are found within a role-configuration, the server shall enforce that deny rule takes precedence over the allow rule.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_REQ 2 If conflicting/overlapping rules are found within a role-configuration, the server shall enforce that deny rule takes precedence over the allow rule. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 5 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00792 | RBAC_REQ 3 If a matching allow/deny rule is found and all the rule settings are fulfilled, the server shall accept/deny the request.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_REQ 3 If a matching allow/deny rule is found and all the rule settings are fulfilled, the server shall accept/deny the request. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 5 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00793 | RBAC_REQ 4 If a matching rule is found and not all the rule settings are fulfilled, the server shall consider the request rejected for that rule.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_REQ 4 If a matching rule is found and not all the rule settings are fulfilled, the server shall consider the request rejected for that rule. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 5 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00794 | RBAC_REQ 5 The server shall deny a request if no matching rule is found on RBACC.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_REQ 5 The server shall deny a request if no matching rule is found on RBACC. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 5 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00795 | RBAC_INFO 10 All RBACC ALLOW rules have a setting that dictates if a request, matching the rule, must be 14229-1:2020).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_INFO 10 All RBACC ALLOW rules have a setting that dictates if a request, matching the rule, must be 14229-1:2020). Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 5 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00796 | RBAC_REQ 6 The server shall evaluate each role-configuration independently from each other.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_REQ 6 The server shall evaluate each role-configuration independently from each other. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 6 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00797 | RBAC_REQ 27 The server shall require that requests are authenticated for allow rules, using e.g., SecuredDataTransmission 0x84 (see CVS31, ISO-14229-1:2020).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_REQ 27 The server shall require that requests are authenticated for allow rules, using e.g., SecuredDataTransmission 0x84 (see CVS31, ISO-14229-1:2020). Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 6 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00798 | Page 7 RBACC Role-configuration role Pattern-rule DENY Pattern-rule ALLOW DID-rule DENY DID-rule ALLOW RID-rule DENY RID-rule ALLOW Figure 2 – Visual representation of the RBACC 3.3 ASN.1 definition RBAC_REQ 7 The server and client shall define the RBACC as per the following ASN.1 definition: RBACC ::= SEQUENCE { version OCTET STRING (SIZE(2)), rbacc-id OCTET STRING (SIZE(16)), role-configurations SEQUENCE (SIZE(0..MAX)) OF Role-configuration } Role-configuration ::= SEQUENCE { role INTEGER(0..MAX), pattern-rules-deny SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(2..MAX)), pattern-rules-allow SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(2..MAX)), did-rules-deny SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(3)), did-rules-allow SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(3)), rid-rules-deny SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(3)), rid-rules-allow SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(3)) }Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Page 7 RBACC Role-configuration role Pattern-rule DENY Pattern-rule ALLOW DID-rule DENY DID-rule ALLOW RID-rule DENY RID-rule ALLOW Figure 2 – Visual representation of the RBACC 3.3 ASN.1 definition RBAC_REQ 7 The server and client shall define the RBACC as per the following ASN.1 definition: RBACC ::= SEQUENCE { version OCTET STRING (SIZE(2)), rbacc-id OCTET STRING (SIZE(16)), role-configurations SEQUENCE (SIZE(0..MAX)) OF Role-configuration } Role-configuration ::= SEQUENCE { role INTEGER(0..MAX), pattern-rules-deny SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(2..MAX)), pattern-rules-allow SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(2..MAX)), did-rules-deny SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(3)), did-rules-allow SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(3)), rid-rules-deny SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(3)), rid-rules-allow SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(3)) } Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 7 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00799 | RBAC_REQ 8 The server shall support in the version field two octets.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_REQ 8 The server shall support in the version field two octets. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 8 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00800 | RBAC_REQ 9 The server shall support major version value 3 and minor version value 0.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_REQ 9 The server shall support major version value 3 and minor version value 0. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 8 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00801 | RBAC_INFO 19 If other versions shall be supported is out of the scope of this document and shall be agreed upon between projects in Traton.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_INFO 19 If other versions shall be supported is out of the scope of this document and shall be agreed upon between projects in Traton. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 8 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00802 | RBAC_REQ 10 Before RBACC is stored, the server shall verify that the server supports the structure indicated in the version number.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC; Data Authenticity and Integrity Verification | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_REQ 10 Before RBACC is stored, the server shall verify that the server supports the structure indicated in the version number. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Data Authenticity and Integrity Verification. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 8 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00803 | If the version number does not comply with the server implementation, the server shall reject storing the data.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: If the version number does not comply with the server implementation, the server shall reject storing the data. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 8 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00804 | RBAC_REQ 11 The server shall report the currently stored RBACC’s version via diagnostics.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_REQ 11 The server shall report the currently stored RBACC’s version via diagnostics. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 8 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00805 | RBAC_REQ 12 The server shall support 16 octets in the rbacc-id field.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_REQ 12 The server shall support 16 octets in the rbacc-id field. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 8 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00806 | RBAC_REQ 13 The server shall report the currently stored RBACC’s rbacc-id via diagnostics.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_REQ 13 The server shall report the currently stored RBACC’s rbacc-id via diagnostics. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 8 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00807 | RBAC_REQ 14 The server shall support role-configurations using 32-bit unsigned integer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_REQ 14 The server shall support role-configurations using 32-bit unsigned integer. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 8 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00808 | Page 9 3.7 pattern-rules RBAC_REQ 15 The server shall support for every entry in the pattern-rules one octet for the pattern rule settings followed by the diagnostic pattern of variable length.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA; Diagnostic security | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Page 9 3.7 pattern-rules RBAC_REQ 15 The server shall support for every entry in the pattern-rules one octet for the pattern rule settings followed by the diagnostic pattern of variable length. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA; Diagnostic security. Architecture view: Security Services. Mapped security capability: Diagnostic security Mapped feature: Diagnostic security Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00809 | RBAC_REQ 16 The server shall support the pattern-rule setting according to Table 1.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_REQ 16 The server shall support the pattern-rule setting according to Table 1. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00810 | Table 1 – Pattern Rule Settings Bit index Name Description 0 Reserved Reserved 1 UDS 0 == This rule is not valid for a UDS-server 1 == This rule is valid for a UDS-server This bit shall always assume value 1 2 Reserved Reserved 3 Confidentiality 0 == No confidentiality is required on the diagnostics request 1 == Confidentiality is required on the diagnostics request e.g., 0x84 (CVS32) Note: This bit is supported but not used for deny rules.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Table 1 – Pattern Rule Settings Bit index Name Description 0 Reserved Reserved 1 UDS 0 == This rule is not valid for a UDS-server 1 == This rule is valid for a UDS-server This bit shall always assume value 1 2 Reserved Reserved 3 Confidentiality 0 == No confidentiality is required on the diagnostics request 1 == Confidentiality is required on the diagnostics request e.g., 0x84 (CVS32) Note: This bit is supported but not used for deny rules. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00811 | 4-7 N/A Reserved for future use 3.8 did-rules RBAC_REQ 17 The server shall support for every entry in the did-rules one octet which represents the did-rule settings followed by two octets that represent the DID.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 4-7 N/A Reserved for future use 3.8 did-rules RBAC_REQ 17 The server shall support for every entry in the did-rules one octet which represents the did-rule settings followed by two octets that represent the DID. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00812 | RBAC_REQ 18 The byte order for DID shall be big endian.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_REQ 18 The byte order for DID shall be big endian. Engineering expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00813 | RBAC_REQ 19 The server shall support the did-rule setting according to Table 2.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_REQ 19 The server shall support the did-rule setting according to Table 2. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00814 | Page 10 Table 2 – DID Rule Settings Bit index Name Description 0 Reserved Reserved 1 UDS 0 == This rule is not valid for a UDS-server 1 == This rule is valid for a UDS-server This bit shall always assume value 1 2 Reserved Reserved 3 Confidentiality 0 == No confidentiality is required on the diagnostics request 1 == Confidentiality is required on the diagnostics request e.g., 0x84 (CVS32) Note: This bit is supported but not used for deny rules.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Page 10 Table 2 – DID Rule Settings Bit index Name Description 0 Reserved Reserved 1 UDS 0 == This rule is not valid for a UDS-server 1 == This rule is valid for a UDS-server This bit shall always assume value 1 2 Reserved Reserved 3 Confidentiality 0 == No confidentiality is required on the diagnostics request 1 == Confidentiality is required on the diagnostics request e.g., 0x84 (CVS32) Note: This bit is supported but not used for deny rules. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00815 | 4 Read 0 == This rule is not applicable when the DID is being read 1 == This rule is applicable when the DID is being read 5 Write 0 == This rule is not applicable when the DID is being written 1 == This rule is applicable when the DID is being written 6 IO-control 0 == This rule is not applicable when the DID is being used for IO-control 1 == This rule is applicable when the DID is being used for IO-control 7 N/A Reserved for future use 3.9 rid-rules RBAC_REQ 20 The server shall support for every entry in the rid-rules one octet which represents the rid-rule settings followed by two octets that represent the RID.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 4 Read 0 == This rule is not applicable when the DID is being read 1 == This rule is applicable when the DID is being read 5 Write 0 == This rule is not applicable when the DID is being written 1 == This rule is applicable when the DID is being written 6 IO-control 0 == This rule is not applicable when the DID is being used for IO-control 1 == This rule is applicable when the DID is being used for IO-control 7 N/A Reserved for future use 3.9 rid-rules RBAC_REQ 20 The server shall support for every entry in the rid-rules one octet which represents the rid-rule settings followed by two octets that represent the RID. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00816 | RBAC_REQ 21 The server shall support the rid-rule setting according to Table 3.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_REQ 21 The server shall support the rid-rule setting according to Table 3. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00817 | Page 11 Table 3 – RID Rule Setting Bit index Name Description 0 Reserved Reserved 1 UDS 0 == This rule is not valid for a UDS-server 1 == This rule is valid for a UDS-server This bit shall always assume value 1 2 Reserved Reserved 3 Confidentiality 0 == No confidentiality is required on the diagnostics request 1 == Confidentiality is required on the diagnostics request e.g., 0x84 (CVS32) Note: This bit is supported but not used for deny rules.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Page 11 Table 3 – RID Rule Setting Bit index Name Description 0 Reserved Reserved 1 UDS 0 == This rule is not valid for a UDS-server 1 == This rule is valid for a UDS-server This bit shall always assume value 1 2 Reserved Reserved 3 Confidentiality 0 == No confidentiality is required on the diagnostics request 1 == Confidentiality is required on the diagnostics request e.g., 0x84 (CVS32) Note: This bit is supported but not used for deny rules. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00818 | RBAC_REQ 22 If conflicting/overlapping rules are found between the client certificate D-RBACC extension and any rules in the RBAC-configuration in the RBACC, the server shall enforce the rules in the client certificate D-RBACC extension.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Secure Diagnostics and RBAC; Key and Certificate Handling; Certificate handling | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_REQ 22 If conflicting/overlapping rules are found between the client certificate D-RBACC extension and any rules in the RBAC-configuration in the RBACC, the server shall enforce the rules in the client certificate D-RBACC extension. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Key and Certificate Handling; Certificate handling. Architecture view: Security Services. Mapped security capability: Certificate handling Mapped feature: Certificate handling Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00819 | Page 12 RBAC_REQ 23 The server shall interpret the extnValue (see snipped above) as of one instance of a RBACC (see 3.3).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Page 12 RBAC_REQ 23 The server shall interpret the extnValue (see snipped above) as of one instance of a RBACC (see 3.3). Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00820 | It can also be useful if you want to add or remove access rights from a client/tester, that needs access to one or several roles, but should not have access to everything (or should have more access) specified for the assigned roles.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: It can also be useful if you want to add or remove access rights from a client/tester, that needs access to one or several roles, but should not have access to everything (or should have more access) specified for the assigned roles. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 12 Classification: Not Applicable Mandatory level: Should Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00821 | 3.11 ECU-Diagnostics-Role Extension RBAC_REQ 36 The server shall exert the RBACC roles based on the ECU-diagnostics-Role extension on the client’s certificate.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Key and Certificate Handling; Cybersecurity Evidence and DIA; Certificate handling | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 3.11 ECU-Diagnostics-Role Extension RBAC_REQ 36 The server shall exert the RBACC roles based on the ECU-diagnostics-Role extension on the client’s certificate. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Key and Certificate Handling; Cybersecurity Evidence and DIA; Certificate handling. Architecture view: Security Services. Mapped security capability: Certificate handling Mapped feature: Certificate handling Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00822 | Page 13 Figure 3 – Logic Overview RBAC_REQ 35 The server shall implement RBAC internal logic as per Figure 4.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Secure Diagnostics and RBAC; Security Logging and Event Handling | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Page 13 Figure 3 – Logic Overview RBAC_REQ 35 The server shall implement RBAC internal logic as per Figure 4. Engineering expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Security Logging and Event Handling. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 13 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00823 | RBAC_REQ 32 The server shall implement RBAC pattern rule evaluation logic as per Figure 5.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Secure Diagnostics and RBAC; Security Logging and Event Handling | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_REQ 32 The server shall implement RBAC pattern rule evaluation logic as per Figure 5. Engineering expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Security Logging and Event Handling. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 15 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00824 | E.g: For the evaluate pattern the rule setting Confidentiality is set to 0x01 (Confidentiality is required).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: E.g: For the evaluate pattern the rule setting Confidentiality is set to 0x01 (Confidentiality is required). Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 16 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00825 | RBAC_REQ 33 The server shall implement RBAC did rule evaluate as per Figure 6.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_REQ 33 The server shall implement RBAC did rule evaluate as per Figure 6. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 16 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00826 | Page 17 RBAC_REQ 34 The server shall implement RBAC rid rule evaluate as per Figure 7.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Page 17 RBAC_REQ 34 The server shall implement RBAC rid rule evaluate as per Figure 7. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 17 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00827 | Meaning, role 0 is particularly useful for defining services, DIDs and RIDs that should be available to all clients/users, regardless of their diagnostics role and/or authorization/authentication status.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Key and Certificate Handling; Cybersecurity Evidence and DIA | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Meaning, role 0 is particularly useful for defining services, DIDs and RIDs that should be available to all clients/users, regardless of their diagnostics role and/or authorization/authentication status. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Key and Certificate Handling; Cybersecurity Evidence and DIA. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 19 Classification: Not Applicable Mandatory level: Should Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00828 | RBAC_REQ 24 The server shall allow requests that are contained in role 0 rules regardless of the client authentication state.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC; Key and Certificate Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_REQ 24 The server shall allow requests that are contained in role 0 rules regardless of the client authentication state. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Key and Certificate Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 19 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00829 | RBAC_REQ 25 The server shall allow request that are contained in role 0 rule regardless if the request is data authenticated e.g over e.g., SecuredDataTransmission 0x84 (See CVS31, ISO 14229-1:2020).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_REQ 25 The server shall allow request that are contained in role 0 rule regardless if the request is data authenticated e.g over e.g., SecuredDataTransmission 0x84 (See CVS31, ISO 14229-1:2020). Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 19 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00830 | RBAC_REQ 26 The server shall allow request that are contained in role 0 rule regardless of the value of Confidentiality field setting.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_REQ 26 The server shall allow request that are contained in role 0 rule regardless of the value of Confidentiality field setting. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 19 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00831 | RBAC_INFO 40 This means that in role 0 encryption is never required.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_INFO 40 This means that in role 0 encryption is never required. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 19 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00832 | 3.14 Requests Specific Requirements 3.14.1 Diagnostic over USD 3.14.1.1 Authenticate 0x29 RBAC_REQ 28 The server shall always allow reception of UDS authenticate 0x29 requests regardless of the RBACC settings.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA; Authentication | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 3.14 Requests Specific Requirements 3.14.1 Diagnostic over USD 3.14.1.1 Authenticate 0x29 RBAC_REQ 28 The server shall always allow reception of UDS authenticate 0x29 requests regardless of the RBACC settings. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA; Authentication. Architecture view: Security Services. Mapped security capability: Authentication Mapped feature: Authentication Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 19 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00833 | RBAC_INFO 42 For 0x29 requests a corresponding matching rule in the RBACC is not required for the server to accept the request.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_INFO 42 For 0x29 requests a corresponding matching rule in the RBACC is not required for the server to accept the request. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 19 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00834 | 3.14.1.2 SecuredData Transmission 0x84 RBAC_REQ 29 The server shall evaluate the reported internal service using the RBACC rules whenever it receives a UDS Service 0x84 requests.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 3.14.1.2 SecuredData Transmission 0x84 RBAC_REQ 29 The server shall evaluate the reported internal service using the RBACC rules whenever it receives a UDS Service 0x84 requests. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 19 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00835 | RBAC_REQ 30 The server shall always allow reception of UDS SecuredDataTransmission 0x84 requests regardless of the RBACC settings.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_REQ 30 The server shall always allow reception of UDS SecuredDataTransmission 0x84 requests regardless of the RBACC settings. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 19 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00836 | RBAC_INFO 43 For 0x84 requests a corresponding matching rule in the RBACC is not required for the server to accept the 0x84 request but the server must find a corresponding matching rule for the internal request contained in the 0x84 prior to execute it.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_INFO 43 For 0x84 requests a corresponding matching rule in the RBACC is not required for the server to accept the 0x84 request but the server must find a corresponding matching rule for the internal request contained in the 0x84 prior to execute it. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 19 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00837 | Page 20 3.14.1.3 TesterPresent 0x3E RBAC_REQ 31 The server shall always allow reception of UDS TesterPresent 0x3E requests regardless of the RBACC settings.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Page 20 3.14.1.3 TesterPresent 0x3E RBAC_REQ 31 The server shall always allow reception of UDS TesterPresent 0x3E requests regardless of the RBACC settings. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 20 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00838 | RBAC_INFO 44 For 0x3E requests a corresponding matching rule in the RBACC is not required for the server to accept the request.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: RBAC_INFO 44 For 0x3E requests a corresponding matching rule in the RBACC is not required for the server to accept the request. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 20 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00839 | Page 26 Annex D DynamicallyDefineDataIdentifier When this service is being used, each DID included in the request must be evaluated against the rules that are applicable for the client (the rules in the client’s certificate and in the RBACC).Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Key and Certificate Handling; Certificate handling | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Page 26 Annex D DynamicallyDefineDataIdentifier When this service is being used, each DID included in the request must be evaluated against the rules that are applicable for the client (the rules in the client’s certificate and in the RBACC). Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Key and Certificate Handling; Certificate handling. Architecture view: Security Services. Mapped security capability: Certificate handling Mapped feature: Certificate handling Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 26 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00840 | The client must have read access for all included DIDs and have access to the service themselves.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: The client must have read access for all included DIDs and have access to the service themselves. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 26 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00841 | When the client is performing the actual read operation (ReadDataByIdentifier [7]), the conditions and rules for all DIDs, aliased by the dynamically defined identifier, must be met, otherwise the request shall be rejected with an appropriate NRC.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: When the client is performing the actual read operation (ReadDataByIdentifier [7]), the conditions and rules for all DIDs, aliased by the dynamically defined identifier, must be met, otherwise the request shall be rejected with an appropriate NRC. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 26 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00842 | Since reading of DIDs can be allowed by either a pattern-rule (starting with 22 [7]) and/or a DID-rule, both the pattern-rules and the DID-rules must be parsed when evaluating each DID.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: Since reading of DIDs can be allowed by either a pattern-rule (starting with 22 [7]) and/or a DID-rule, both the pattern-rules and the DID-rules must be parsed when evaluating each DID. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: CVS151.pdf Source Markdown: converted/markdown-cleaned/CVS151.md Page reference: page 26 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00843 | Data Security Container base definition Foreword This Commercial Vehicle Standard (“CVS154”) contains requirement specifications for TRATON Group and may be referred to by any of its commercial vehicle Affiliates.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | None | Interface: None Architecture: None Status: Missing security feature, interface, architecture | Medium Needed | DetailsFull requirement statement: Data Security Container base definition Foreword This Commercial Vehicle Standard (“CVS154”) contains requirement specifications for TRATON Group and may be referred to by any of its commercial vehicle Affiliates. Engineering expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Engineering interpretation: Traceability needs review before this requirement can be used as design evidence. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 1 Classification: Reclassified as Assumption Mandatory level: May Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00844 | Any review of this CVS154 shall only be done in agreement with the involved TRATON Group commercial vehicle Affiliates stated in the table below under section “Technical responsibility”.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Compliance Process Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Any review of this CVS154 shall only be done in agreement with the involved TRATON Group commercial vehicle Affiliates stated in the table below under section “Technical responsibility”. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 1 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00845 | The User shall apply the latest version of this CVS154.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The User shall apply the latest version of this CVS154. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 1 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00846 | This document shall be used accompanied with these specifications.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: This document shall be used accompanied with these specifications. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 3 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00847 | DSC_BASE_REQ 37 The server shall support a DSC Metadata block containing version and id fields.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: DSC_BASE_REQ 37 The server shall support a DSC Metadata block containing version and id fields. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 5 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00848 | DSC_BASE_REQ 43 The server shall support the Major and Minor version as specified in 3.2.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: DSC_BASE_REQ 43 The server shall support the Major and Minor version as specified in 3.2. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 5 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00849 | DSC_BASE_REQ 29 The server shall support a DSC containing verificationEntries.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA | Interface: OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: DSC_BASE_REQ 29 The server shall support a DSC containing verificationEntries. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA. Interface view: OEM/Customer Review Interface. Architecture view: Backend and IT Systems; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Backend and IT integration; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: Backend and IT Systems; OEM/Customer Review Interface Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 5 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00850 | DSC_BASE_REQ 30 The server shall support a DSC containing encryptionEntries.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: DSC_BASE_REQ 30 The server shall support a DSC containing encryptionEntries. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 5 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00851 | DSC_BASE_REQ 31 The server shall support a DSC containing itemEntries.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: DSC_BASE_REQ 31 The server shall support a DSC containing itemEntries. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 5 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00852 | DSC_BASE_REQ 45 The server shall expect an ASN.1 SEQUENCE tag with length zero for verificationEntries that contains no VerificationEntry items in a DSC transmitted by the client.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA | Interface: OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: DSC_BASE_REQ 45 The server shall expect an ASN.1 SEQUENCE tag with length zero for verificationEntries that contains no VerificationEntry items in a DSC transmitted by the client. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA. Interface view: OEM/Customer Review Interface. Architecture view: Backend and IT Systems; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Backend and IT integration; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: Backend and IT Systems; OEM/Customer Review Interface Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 5 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00853 | DSC_BASE_REQ 46 The server shall expect an ASN.1 SEQUENCE tag with length zero for encryptionEntries that contains no EncryptionEntry items in a DSC transmitted by the client.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: DSC_BASE_REQ 46 The server shall expect an ASN.1 SEQUENCE tag with length zero for encryptionEntries that contains no EncryptionEntry items in a DSC transmitted by the client. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 5 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00854 | DSC_BASE_REQ 49 The server shall expect an ASN.1 SEQUENCE tag with length zero for ItemEntries that contains no items in a DSC transmitted by the client.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: DSC_BASE_REQ 49 The server shall expect an ASN.1 SEQUENCE tag with length zero for ItemEntries that contains no items in a DSC transmitted by the client. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 5 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00855 | DSC_BASE_REQ 26 The server shall support an empty DSC containing only Metadata (version and id) and the empty sequences for verificationEntries, encryptionEntries and ItemEntries.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA | Interface: OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: DSC_BASE_REQ 26 The server shall support an empty DSC containing only Metadata (version and id) and the empty sequences for verificationEntries, encryptionEntries and ItemEntries. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA. Interface view: OEM/Customer Review Interface. Architecture view: Backend and IT Systems; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Backend and IT integration; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: Backend and IT Systems; OEM/Customer Review Interface Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 5 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00856 | DSC_BASE_INFO 44 An empty DSC issued by client means that in addition to Metadata, the syntax must be correct in accordance with Annex B.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: DSC_BASE_INFO 44 An empty DSC issued by client means that in addition to Metadata, the syntax must be correct in accordance with Annex B. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 5 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00857 | Page 6 DSC_BASE_INFO 33 A DSC containing only version and id states that verification and encryption is not to be performed by the server, although the server shall have the support.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA | Interface: OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: Page 6 DSC_BASE_INFO 33 A DSC containing only version and id states that verification and encryption is not to be performed by the server, although the server shall have the support. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA. Interface view: OEM/Customer Review Interface. Architecture view: Backend and IT Systems; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Backend and IT integration; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: Backend and IT Systems; OEM/Customer Review Interface Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 6 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00858 | 3.1.1.1 HashCmp DSC_BASE_REQ 5 VerificationEntry hashCmp states that a hash comparison shall be used to verify the data.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: 3.1.1.1 HashCmp DSC_BASE_REQ 5 VerificationEntry hashCmp states that a hash comparison shall be used to verify the data. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 6 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00859 | However, the instance specification may state specialized actions: • Server processes each VerificationEntry one by one.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: However, the instance specification may state specialized actions: • Server processes each VerificationEntry one by one. Engineering expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA. Mapped security capability: None Mapped feature: Security evidence and traceability Mapped interface: None Mapped architecture element: None Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 6 Classification: Reclassified as Assumption Mandatory level: May Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00860 | Page 7 • hashAlgorithm: States which HashAlgorithm (see RFC 6234) shall be used for hashing the data to verify.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Page 7 • hashAlgorithm: States which HashAlgorithm (see RFC 6234) shall be used for hashing the data to verify. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 7 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00861 | • dataRanges: sequence of Range itemsRange: Information on which data chunks that shall be verified.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: • dataRanges: sequence of Range items - Range: Information on which data chunks that shall be verified. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 7 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00862 | DSC_BASE_REQ 47 The server shall support the SHA512 HashAlgorithm as referred in 3.2 ASN1 definition.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: DSC_BASE_REQ 47 The server shall support the SHA512 HashAlgorithm as referred in 3.2 ASN1 definition. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 7 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00863 | DSC_BASE_REQ 39 For crypto agility reasons, both of the choices shall be supported by the server.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: DSC_BASE_REQ 39 For crypto agility reasons, both of the choices shall be supported by the server. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 7 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00864 | DSC_BASE_REQ 11 The initial counter value shall be set to 0 (zero).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: DSC_BASE_REQ 11 The initial counter value shall be set to 0 (zero). Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 7 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00865 | Range: Information on which data chunks that shall be decrypted.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Range: Information on which data chunks that shall be decrypted. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 8 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00866 | 3.2 DSC ASN.1 definition DSC_BASE_REQ 41 The structure version for this document release shall be: Major ‘04’ and Minor ‘00’ DSC_BASE_REQ 42 The server shall have support for the ASN.1 contents as defined: DataSecurityContainer ::= SEQUENCE { version OCTET STRING (SIZE(2)), id OCTET STRING (SIZE(16)), verificationEntries SEQUENCE (SIZE(0..MAX)) OF VerificationEntry, encryptionEntries SEQUENCE (SIZE(0..MAX)) OF EncryptionEntry, itemEntries SEQUENCE (SIZE(0..MAX)) OF ItemEntry } VerificationEntry ::= CHOICE { hashCmp [0] EXPLICIT HashCmp }Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA | Interface: OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface Status: Complete | Medium Needed | DetailsFull requirement statement: 3.2 DSC ASN.1 definition DSC_BASE_REQ 41 The structure version for this document release shall be: Major ‘04’ and Minor ‘00’ DSC_BASE_REQ 42 The server shall have support for the ASN.1 contents as defined: DataSecurityContainer ::= SEQUENCE { version OCTET STRING (SIZE(2)), id OCTET STRING (SIZE(16)), verificationEntries SEQUENCE (SIZE(0..MAX)) OF VerificationEntry, encryptionEntries SEQUENCE (SIZE(0..MAX)) OF EncryptionEntry, itemEntries SEQUENCE (SIZE(0..MAX)) OF ItemEntry } VerificationEntry ::= CHOICE { hashCmp [0] EXPLICIT HashCmp } Engineering expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA. Interface view: OEM/Customer Review Interface. Architecture view: Backend and IT Systems; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Backend and IT integration; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: Backend and IT Systems; OEM/Customer Review Interface Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00867 | DSC_BASE_REQ 19 Upon reception of a DSC to the server, before the DSC is stored in NVM, the DSC shall be semantically verified by parsing all its content.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: DSC_BASE_REQ 19 Upon reception of a DSC to the server, before the DSC is stored in NVM, the DSC shall be semantically verified by parsing all its content. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Secure communication and freshness protection; Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00868 | DSC_BASE_REQ 51 The length of the version field shall be verified.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: DSC_BASE_REQ 51 The length of the version field shall be verified. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ_DSC_BASE-20 | REQ_DSC_BASE 20 The version shall be verified with the servers supported Major and Minor version of the DSC logic for compliancy.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Security Logging and Event Handling | Interface: None Architecture: Application Software Status: Missing interface | High Not needed | DetailsFull requirement statement: REQ_DSC_BASE 20 The version shall be verified with the servers supported Major and Minor version of the DSC logic for compliancy. Engineering expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Engineering interpretation: Security view: Security Logging and Event Handling. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00870 | DSC_BASE_REQ 34 The length of the id field shall be verified.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: DSC_BASE_REQ 34 The length of the id field shall be verified. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00871 | DSC_BASE_REQ 27 The hashAlgorithm shall be supported by the server.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: DSC_BASE_REQ 27 The hashAlgorithm shall be supported by the server. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00872 | Page 11 DSC_BASE_REQ 50 The length of every referenceHash shall be consistent with the output size of the hash algorithm specified in the hashAlgorithm.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Page 11 DSC_BASE_REQ 50 The length of every referenceHash shall be consistent with the output size of the hash algorithm specified in the hashAlgorithm. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00873 | DSC_BASE_INFO 35 The verification of servers support of specified dataRanges in the VerificationEntry, shall be stated for the DSC instance.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: DSC_BASE_INFO 35 The verification of servers support of specified dataRanges in the VerificationEntry, shall be stated for the DSC instance. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00874 | DSC_BASE_REQ 28 The EncryptionEntry algorithm shall be supported by the server.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: DSC_BASE_REQ 28 The EncryptionEntry algorithm shall be supported by the server. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00875 | DSC_BASE_REQ 22 The length of key and iv shall be verified accordingly to the algorithm stipulated in EncryptionEntry.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Key and Certificate Handling; Key management | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: DSC_BASE_REQ 22 The length of key and iv shall be verified accordingly to the algorithm stipulated in EncryptionEntry. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Key and Certificate Handling; Key management. Architecture view: Security Services. Mapped security capability: Key management Mapped feature: Key management Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00876 | DSC_BASE_INFO 36 The verification of servers support of specified dataRanges in the EncryptionEntry, shall be stated for the DSC instance.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: DSC_BASE_INFO 36 The verification of servers support of specified dataRanges in the EncryptionEntry, shall be stated for the DSC instance. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00877 | DSC_BASE_REQ 48 If the DSC instance is rejected by the server (see Annex A) when transmitted with EMP, an error code shall be returned to the client.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: DSC_BASE_REQ 48 If the DSC instance is rejected by the server (see Annex A) when transmitted with EMP, an error code shall be returned to the client. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00878 | The sequence tags for verificationEntries, encryptionEntries and itemEntries are required but empty (zero length).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: The sequence tags for verificationEntries, encryptionEntries and itemEntries are required but empty (zero length). Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Cybersecurity Evidence and DIA. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: CVS154.pdf Source Markdown: converted/markdown-cleaned/CVS154.md Page reference: page 14 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00879 | The User shall apply the latest version of this CVS31.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The User shall apply the latest version of this CVS31. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 1 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00880 | Internal Page 3 (31) Foreword This CVS31 contains requirement specification for TRATON GROUP and may be used by all within TRATON Group, if applicable.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: None Status: Missing security feature, interface, architecture | Low Not needed | DetailsFull requirement statement: Internal Page 3 (31) Foreword This CVS31 contains requirement specification for TRATON GROUP and may be used by all within TRATON Group, if applicable. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Traceability needs review before this requirement can be used as design evidence. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 3 Classification: Needs Manual Markdown Correction Mandatory level: May Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ-AUTO-00881 | Any review of CVS31 shall only be done in agreement with the involved departments stated in the table on the first page under section “Technical responsibility”.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Compliance Process Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Any review of CVS31 shall only be done in agreement with the involved departments stated in the table on the first page under section “Technical responsibility”. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 3 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00882 | The whole standard has been reworked and shall be read in its entirety.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The whole standard has been reworked and shall be read in its entirety. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 3 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00883 | • Affiliate means any legal entity that directly or indirectly controls, is controlled by, or is commonly controlled with TRATON SE, it is being understood that “control” shall mean ownership of at least 50% of the voting rights or interest in the issued share capital, including for the avoidance of doubt any branch.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: • Affiliate means any legal entity that directly or indirectly controls, is controlled by, or is commonly controlled with TRATON SE, it is being understood that “control” shall mean ownership of at least 50% of the voting rights or interest in the issued share capital, including for the avoidance of doubt any branch. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 3 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00884 | Any deviations from this specification shall be documented and must be reviewed by the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Missing security feature | Medium Not needed | DetailsFull requirement statement: Any deviations from this specification shall be documented and must be reviewed by the vehicle manufacturer. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 4 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00885 | Shall be agreed between the supplier and the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Supplier Development and Production Hardening | Interface: OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: Shall be agreed between the supplier and the vehicle manufacturer. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Supplier Development and Production Hardening. Interface view: OEM/Customer Review Interface. Architecture view: System Core; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: System behavior Mapped interface: OEM/Customer Review Interface Mapped architecture element: System Core; OEM/Customer Review Interface Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 6 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00886 | It contains the information required for the server to verify the client’s subsequent request and to generate the corresponding response.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: It contains the information required for the server to verify the client’s subsequent request and to generate the corresponding response. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 6 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00887 | It contains the information required for the server to maintain continuous authenticated communication with the client and to generate authenticated responses.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: It contains the information required for the server to maintain continuous authenticated communication with the client and to generate authenticated responses. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 6 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00888 | AUTH_REQ 1 The server shall only support subfunctions in Table 4.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 1 The server shall only support subfunctions in Table 4. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 7 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00889 | Table 4 – Supported subFunctions (ISO 14229-1:2020) Name verifyCertificateBidirectional proofOfOwnership deAuthenticate AUTH_REQ 155 The server shall not accept an application-layer service 0x29 request when it is received inside an SDT (service 0x84) protected message.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Key and Certificate Handling | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Table 4 – Supported subFunctions (ISO 14229-1:2020) Name verifyCertificateBidirectional proofOfOwnership deAuthenticate AUTH_REQ 155 The server shall not accept an application-layer service 0x29 request when it is received inside an SDT (service 0x84) protected message. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Key and Certificate Handling. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; Secure communication and freshness protection Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 7 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00890 | If such an encapsulated 0x29 request is detected, the server shall return application-layer NRC 0x39, provided as a correctly formatted SDT positive response.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: If such an encapsulated 0x29 request is detected, the server shall return application-layer NRC 0x39, provided as a correctly formatted SDT positive response. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; Secure communication and freshness protection Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 7 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00891 | Internal Page 8 (31) 3.1 verifyCertificateBidirectional 3.1.1 Request AUTH_REQ 2 The request for verifyCertificateBidirectional subfunction shall be formatted according to Table 5.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Data Authenticity and Integrity Verification; Key and Certificate Handling | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Internal Page 8 (31) 3.1 verifyCertificateBidirectional 3.1.1 Request AUTH_REQ 2 The request for verifyCertificateBidirectional subfunction shall be formatted according to Table 5. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Key and Certificate Handling. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 8 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00892 | Table 5 – verifyCertificateBidirectional Request Field Description Type/Value Cvt Included in proofOfOwnershipServer Authentication Request SID Service ID for Authentication service request 0x29 M Yes verifyCertificateBidirectional] Initiate Authentication by verifying the Certificate and generating a Proof of Ownership from the server 0x02 M Yes communicationConfiguration NOT USED 0x00 M Yes lengthOfCertificateClient Length parameter for certificateClient uint16 M Yes certificateClient The Certificate to verify uint8[] M Yes lengthOfChallengeClient Length parameter for challengeClient uint16 M Yes challengeClient See 3.1.1.1 uint8[] M Yes AUTH_REQ 117 Upon reception of a verifyCertificateBidirectional request, the server shall determine whether the Authentication delay timer is currently running.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Key and Certificate Handling; Authentication | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Table 5 – verifyCertificateBidirectional Request Field Description Type/Value Cvt Included in proofOfOwnershipServer Authentication Request SID Service ID for Authentication service request 0x29 M Yes verifyCertificateBidirectional] Initiate Authentication by verifying the Certificate and generating a Proof of Ownership from the server 0x02 M Yes communicationConfiguration NOT USED 0x00 M Yes lengthOfCertificateClient Length parameter for certificateClient uint16 M Yes certificateClient The Certificate to verify uint8[] M Yes lengthOfChallengeClient Length parameter for challengeClient uint16 M Yes challengeClient See 3.1.1.1 uint8[] M Yes AUTH_REQ 117 Upon reception of a verifyCertificateBidirectional request, the server shall determine whether the Authentication delay timer is currently running. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Key and Certificate Handling; Authentication. Architecture view: Security Services. Mapped security capability: Authentication Mapped feature: Authentication Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 8 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00893 | AUTH_REQ 118 If upon reception of verifyCertificateBidirectional request the Authentication delay timer is expired, the server shall continue to process the verifyCertificateBidirectional request.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Data Authenticity and Integrity Verification; Key and Certificate Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 118 If upon reception of verifyCertificateBidirectional request the Authentication delay timer is expired, the server shall continue to process the verifyCertificateBidirectional request. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Key and Certificate Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 8 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00894 | AUTH_INFO 24 The column “Included in proofOfOwnershipServer”, present in several message-definition tables, indicates whether the corresponding field shall be covered by the proofOfOwnershipServer signature computed by the server and included in its response.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification; Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_INFO 24 The column “Included in proofOfOwnershipServer”, present in several message-definition tables, indicates whether the corresponding field shall be covered by the proofOfOwnershipServer signature computed by the server and included in its response. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 8 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00895 | AUTH_REQ 45 If the server verifies the client certificate as valid, the server shall create the requested client authentication pending state.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Key and Certificate Handling; Authentication | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 45 If the server verifies the client certificate as valid, the server shall create the requested client authentication pending state. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Key and Certificate Handling; Authentication. Architecture view: Security Services. Mapped security capability: Authentication Mapped feature: Authentication Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 8 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00896 | Internal Page 9 (31) AUTH_REQ 119 If an authentication pending state already exists, the server shall replace the existing authentication pending state with the new one.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Key and Certificate Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Internal Page 9 (31) AUTH_REQ 119 If an authentication pending state already exists, the server shall replace the existing authentication pending state with the new one. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Key and Certificate Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00897 | 3.1.1.1 challengeClient AUTH_REQ 3 This field shall consists of 32 octets.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 3.1.1.1 challengeClient AUTH_REQ 3 This field shall consists of 32 octets. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00898 | AUTH_REQ 4 The challengeClient (ISO 14229-1:2020) shall be generated using a CRNG.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Compliance Process Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 4 The challengeClient (ISO 14229-1:2020) shall be generated using a CRNG. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00899 | 3.1.1.2 lengthOfCertificateClient AUTH_REQ 172 The expected range values of lengthOfCertificateClient shall be from 0x00C8 to 0x0800.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Key and Certificate Handling | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 3.1.1.2 lengthOfCertificateClient AUTH_REQ 172 The expected range values of lengthOfCertificateClient shall be from 0x00C8 to 0x0800. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Key and Certificate Handling. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00900 | AUTH_REQ 173 The server shall verify the value of lengthOfCertificateClient upon reception of verifyCertificateBidirectional request.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Data Authenticity and Integrity Verification; Key and Certificate Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 173 The server shall verify the value of lengthOfCertificateClient upon reception of verifyCertificateBidirectional request. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Key and Certificate Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00901 | AUTH_REQ 174 If the lengthOfCertificateClient value is not within the expected range, the server shall send negative response code 0x13 (incorrectMessageLengthOrInvalidFormat).Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Secure Communication and Boundary Control; Key and Certificate Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 174 If the lengthOfCertificateClient value is not within the expected range, the server shall send negative response code 0x13 (incorrectMessageLengthOrInvalidFormat). Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Secure Communication and Boundary Control; Key and Certificate Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00902 | 3.1.2 Response AUTH_REQ 5 The response for verifyCertificateBidirectional subfunction shall be formatted according to Table 6.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Data Authenticity and Integrity Verification; Key and Certificate Handling | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 3.1.2 Response AUTH_REQ 5 The response for verifyCertificateBidirectional subfunction shall be formatted according to Table 6. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Key and Certificate Handling. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00903 | AUTH_REQ 120 Upon positively responding, the server shall start the Authentication completion timer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Key and Certificate Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 120 Upon positively responding, the server shall start the Authentication completion timer. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Key and Certificate Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00904 | ephemeralPublicKeyServer See 3.1.2.3 uint8[] M Yes 3.1.2.1 challengeServer AUTH_REQ 6 The challengeServer field shall consists of 32 octets generated using a CRNG.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Key and Certificate Handling | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: ephemeralPublicKeyServer See 3.1.2.3 uint8[] M Yes 3.1.2.1 challengeServer AUTH_REQ 6 The challengeServer field shall consists of 32 octets generated using a CRNG. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Key and Certificate Handling. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00905 | AUTH_REQ 7 The proof/signature shall be generated according to the pseudo code below.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 7 The proof/signature shall be generated according to the pseudo code below. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00906 | 3.1.3 Negative Response AUTH_REQ 121 If upon reception of verifyCertificateBidirectional request the Authentication delay timer is running, the server shall respond to the verifyCertificateBidirectional request with a Negative Response Code (NRC) 0x37, indicating requiredTimeDelayNotExpired.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Data Authenticity and Integrity Verification; Key and Certificate Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 3.1.3 Negative Response AUTH_REQ 121 If upon reception of verifyCertificateBidirectional request the Authentication delay timer is running, the server shall respond to the verifyCertificateBidirectional request with a Negative Response Code (NRC) 0x37, indicating requiredTimeDelayNotExpired. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Key and Certificate Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00907 | AUTH_REQ 122 If the server verifies the client certificate as invalid, it shall respond to the verifyCertificateBidirectional request with a Negative Response Code (NRC) 0x10, indicating generalReject.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Data Authenticity and Integrity Verification; Key and Certificate Handling; Authentication | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 122 If the server verifies the client certificate as invalid, it shall respond to the verifyCertificateBidirectional request with a Negative Response Code (NRC) 0x10, indicating generalReject. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Key and Certificate Handling; Authentication. Architecture view: Security Services. Mapped security capability: Authentication Mapped feature: Authentication Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00908 | AUTH_REQ 123 If the server fails or cannot determine that the authentication pending state was stored, it shall respond to the verifyCertificateBidirectional request with a Negative Response Code (NRC) 0x94, indicating ResourceTemporarilyNotAvailable.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Key and Certificate Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 123 If the server fails or cannot determine that the authentication pending state was stored, it shall respond to the verifyCertificateBidirectional request with a Negative Response Code (NRC) 0x94, indicating ResourceTemporarilyNotAvailable. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Key and Certificate Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00909 | Internal Page 12 (31) 3.2.1 Request AUTH_REQ 8 The request for proofOfOwnership subfunction shall be defined according to Table 7.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Internal Page 12 (31) 3.2.1 Request AUTH_REQ 8 The request for proofOfOwnership subfunction shall be defined according to Table 7. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00910 | Table 7 – proofOfOwnership Request Field Description Type/Value Cvt Included in proofOfOwnershipClient Authentication Request SID Service ID for 0x29 M Yes proofOfOwnership] Verify the Proof of Ownership from the client 0x03 M Yes lengthOfProofOfOwnershipClient This field indicates the length (in octets) of the proofOfOwnershipClient field proofOfOwnershipClient See 3.2.1.1 uint8[] M No lengthOfEphemeralPublicKey Client Length parameter for ephemeralPublicKey Client ephemeralPublicKeyClient See 3.2.1.2 uint16 M Yes AUTH_REQ 110 The server shall verify whether any existing authentication pending state corresponds to the client submitting the proofOfOwnership request.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Key and Certificate Handling | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Table 7 – proofOfOwnership Request Field Description Type/Value Cvt Included in proofOfOwnershipClient Authentication Request SID Service ID for 0x29 M Yes proofOfOwnership] Verify the Proof of Ownership from the client 0x03 M Yes lengthOfProofOfOwnershipClient This field indicates the length (in octets) of the proofOfOwnershipClient field proofOfOwnershipClient See 3.2.1.1 uint8[] M No lengthOfEphemeralPublicKey Client Length parameter for ephemeralPublicKey Client ephemeralPublicKeyClient See 3.2.1.2 uint16 M Yes AUTH_REQ 110 The server shall verify whether any existing authentication pending state corresponds to the client submitting the proofOfOwnership request. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Key and Certificate Handling. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00911 | AUTH_REQ 111 If an existing authentication pending state is found, the server shall verify if the Authentication completion timer is currently running.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification; Key and Certificate Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 111 If an existing authentication pending state is found, the server shall verify if the Authentication completion timer is currently running. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Key and Certificate Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00912 | AUTH_REQ 112 If the Authentication completion timer is currently running, the server shall continue to process the client’s proofOfOwnership request.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Key and Certificate Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 112 If the Authentication completion timer is currently running, the server shall continue to process the client’s proofOfOwnership request. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Key and Certificate Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00913 | AUTH_REQ 113 If the client proofOfOwnership signature verification fails, the server shall delete the authentication pending state connected to the client submitting the proofOfOwnership request.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification; Key and Certificate Handling; Cybersecurity Evidence and DIA | Interface: OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 113 If the client proofOfOwnership signature verification fails, the server shall delete the authentication pending state connected to the client submitting the proofOfOwnership request. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Key and Certificate Handling; Cybersecurity Evidence and DIA. Interface view: OEM/Customer Review Interface. Architecture view: Backend and IT Systems; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Backend and IT integration; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: Backend and IT Systems; OEM/Customer Review Interface Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00914 | AUTH_REQ 114 If the server fails or cannot determine that the authentication state was stored, the server shall delete the authentication pending state connected to the client submitting the proofOfOwnership request.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control; Key and Certificate Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 114 If the server fails or cannot determine that the authentication state was stored, the server shall delete the authentication pending state connected to the client submitting the proofOfOwnership request. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control; Key and Certificate Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00915 | AUTH_REQ 115 If the client’s proofOfOwnership signature is successfully verified, the server shall establish a new authentication state for the client.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification; Key and Certificate Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 115 If the client’s proofOfOwnership signature is successfully verified, the server shall establish a new authentication state for the client. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Key and Certificate Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00916 | Internal Page 13 (31) If an active authentication state already exists, the server shall replace the existing state with the newly established one.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Key and Certificate Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Internal Page 13 (31) If an active authentication state already exists, the server shall replace the existing state with the newly established one. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Key and Certificate Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 13 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00917 | AUTH_REQ 160 The proofOfOwnershipClient shall be generated according to the pseudo code below.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 160 The proofOfOwnershipClient shall be generated according to the pseudo code below. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 13 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00918 | 3.2.2 Response AUTH_REQ 161 The response for proofOfOwnership subfunction shall be according to Table 8.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 3.2.2 Response AUTH_REQ 161 The response for proofOfOwnership subfunction shall be according to Table 8. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 13 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00919 | AUTH_REQ 162 The signature shall be generated according to the pseudo code below.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 162 The signature shall be generated according to the pseudo code below. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 14 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00920 | 3.2.3 Negative Response AUTH_REQ 124 If the server determines that the client does not have an existing authentication pending state, it shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x24, indicating requestSequenceError.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Key and Certificate Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 3.2.3 Negative Response AUTH_REQ 124 If the server determines that the client does not have an existing authentication pending state, it shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x24, indicating requestSequenceError. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Key and Certificate Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 14 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00921 | AUTH_REQ 125 If the server determines that the client have an existing authentication pending state and the Authentication completion timer is expired, the server shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x24, indicating requestSequenceError.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Key and Certificate Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 125 If the server determines that the client have an existing authentication pending state and the Authentication completion timer is expired, the server shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x24, indicating requestSequenceError. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Key and Certificate Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 14 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00922 | AUTH_REQ 126 If the server cannot determine if the client does have an existing authentication pending state, it shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x94, indicating ResourceTemporarilyNotAvailable.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control; Key and Certificate Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 126 If the server cannot determine if the client does have an existing authentication pending state, it shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x94, indicating ResourceTemporarilyNotAvailable. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control; Key and Certificate Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 14 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00923 | AUTH_REQ 127 If the server is trying to delete the authentication pending state as consequence of the client proofOfOwnership signature verification failure, and the server determines that the authentication pending state was deleted, it shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x10, indicating generalReject.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification; Key and Certificate Handling; Cybersecurity Evidence and DIA | Interface: OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 127 If the server is trying to delete the authentication pending state as consequence of the client proofOfOwnership signature verification failure, and the server determines that the authentication pending state was deleted, it shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x10, indicating generalReject. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Key and Certificate Handling; Cybersecurity Evidence and DIA. Interface view: OEM/Customer Review Interface. Architecture view: Backend and IT Systems; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Backend and IT integration; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: Backend and IT Systems; OEM/Customer Review Interface Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 14 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00924 | AUTH_REQ 128 If the server is trying to delete the authentication pending state as consequence of the client proofOfOwnership signature verification failure, and the server cannot determine that the authentication pending state was deleted, it shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x94, indicating ResourceTemporarilyNotAvailable.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Key and Certificate Handling; Cybersecurity Evidence and DIA | Interface: OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 128 If the server is trying to delete the authentication pending state as consequence of the client proofOfOwnership signature verification failure, and the server cannot determine that the authentication pending state was deleted, it shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x94, indicating ResourceTemporarilyNotAvailable. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Key and Certificate Handling; Cybersecurity Evidence and DIA. Interface view: OEM/Customer Review Interface. Architecture view: Backend and IT Systems; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Backend and IT integration; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: Backend and IT Systems; OEM/Customer Review Interface Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 14 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00925 | AUTH_REQ 129 If the server is deleting the authentication pending state as consequence of failure to store the authentication state, it shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x94, indicating ResourceTemporarilyNotAvailable.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Key and Certificate Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 129 If the server is deleting the authentication pending state as consequence of failure to store the authentication state, it shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x94, indicating ResourceTemporarilyNotAvailable. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Key and Certificate Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 14 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00926 | 3.3.1 Request AUTH_REQ 159 The request for deAuthenticate subfunction shall be formatted according to Table 9.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 3.3.1 Request AUTH_REQ 159 The request for deAuthenticate subfunction shall be formatted according to Table 9. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 15 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00927 | Table 9 – deAuthenticate request message layout Field Description Type/Value Cvt Authentication Request SID Service ID for 0x29 M SubFunction = [AuthenticationTask = deAuthenticate] Subfunction for request to leave the authenticated state 0x00 M 3.3.2 Response AUTH_REQ 96 The response for deAuthenticate subfunction shall be formatted according to Table 10.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control; Key and Certificate Handling | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Table 9 – deAuthenticate request message layout Field Description Type/Value Cvt Authentication Request SID Service ID for 0x29 M SubFunction = [AuthenticationTask = deAuthenticate] Subfunction for request to leave the authenticated state 0x00 M 3.3.2 Response AUTH_REQ 96 The response for deAuthenticate subfunction shall be formatted according to Table 10. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control; Key and Certificate Handling. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 15 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00928 | 0x00 – 0xFF M AUTH_REQ 158 The server shall delete/invalidate the client’s authentication prior to positively responding to the deAuthenticate request.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Key and Certificate Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 0x00 – 0xFF M AUTH_REQ 158 The server shall delete/invalidate the client’s authentication prior to positively responding to the deAuthenticate request. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Key and Certificate Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 15 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00929 | 3.3.3 Negative Response AUTH_REQ 130 If the server determines that the client is not currently authenticated, it shall respond to the deAuthenticate request with a Negative Response Code (NRC) 0x24, indicating a requestSequenceError.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 3.3.3 Negative Response AUTH_REQ 130 If the server determines that the client is not currently authenticated, it shall respond to the deAuthenticate request with a Negative Response Code (NRC) 0x24, indicating a requestSequenceError. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 15 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00930 | AUTH_REQ 131 If the server cannot determine that the client is currently authenticated, it shall respond to the deAuthenticate request with a Negative Response Code (NRC) 0x94, indicating a ResourceTemporarilyNotAvailable.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 131 If the server cannot determine that the client is currently authenticated, it shall respond to the deAuthenticate request with a Negative Response Code (NRC) 0x94, indicating a ResourceTemporarilyNotAvailable. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 15 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00931 | Internal Page 16 (31) AUTH_REQ 132 If the server is unable to delete the client's authentication state or cannot verify its presence, it shall respond to the deAuthenticate request with Negative Response Code (NRC) 0x94, indicating ResourceTemporarilyNotAvailable.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Key and Certificate Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Internal Page 16 (31) AUTH_REQ 132 If the server is unable to delete the client's authentication state or cannot verify its presence, it shall respond to the deAuthenticate request with Negative Response Code (NRC) 0x94, indicating ResourceTemporarilyNotAvailable. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Key and Certificate Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 16 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00932 | AUTH_INFO 133 If the server is unable to delete the client’s authentication state or cannot retrieve it due to internal errors, the server responds NRC 0x94.This informs the client that the authentication state may still exist on the server.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Secure Communication and Boundary Control; Key and Certificate Handling | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: AUTH_INFO 133 If the server is unable to delete the client’s authentication state or cannot retrieve it due to internal errors, the server responds NRC 0x94.This informs the client that the authentication state may still exist on the server. Engineering expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Engineering interpretation: Security view: Secure Communication and Boundary Control; Key and Certificate Handling. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 16 Classification: Reclassified as Assumption Mandatory level: May Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00933 | 4 General 4.1 Certificate AUTH_REQ 175 The signature algorithm used throughout the authentication process shall be ED25519.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Data Authenticity and Integrity Verification; Key and Certificate Handling; Authentication | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 4 General 4.1 Certificate AUTH_REQ 175 The signature algorithm used throughout the authentication process shall be ED25519. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Key and Certificate Handling; Authentication. Architecture view: Security Services. Mapped security capability: Authentication Mapped feature: Authentication Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 16 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00934 | AUTH_REQ 176 The client shall use the private key corresponding to the client certificate to generate the signatures.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Data Authenticity and Integrity Verification; Key and Certificate Handling; Authentication | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 176 The client shall use the private key corresponding to the client certificate to generate the signatures. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Key and Certificate Handling; Authentication. Architecture view: Security Services. Mapped security capability: Authentication Mapped feature: Authentication Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 16 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00935 | AUTH_REQ 177 The server shall use the private key corresponding to the server certificate to generate the signatures.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Data Authenticity and Integrity Verification; Key and Certificate Handling; Authentication | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 177 The server shall use the private key corresponding to the server certificate to generate the signatures. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Key and Certificate Handling; Authentication. Architecture view: Security Services. Mapped security capability: Authentication Mapped feature: Authentication Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 16 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00936 | AUTH_REQ 163 The format and the structure of the certificates shall be based on (CVS30).Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Key and Certificate Handling | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 163 The format and the structure of the certificates shall be based on (CVS30). Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Key and Certificate Handling. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 16 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00937 | AUTH_REQ 164 The server shall reject a received client’s certificate, sent using the verifyCertificateBidirectional subFunction, if it matches the server’s own certificate.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Data Authenticity and Integrity Verification; Key and Certificate Handling; Authentication | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 164 The server shall reject a received client’s certificate, sent using the verifyCertificateBidirectional subFunction, if it matches the server’s own certificate. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Key and Certificate Handling; Authentication. Architecture view: Security Services. Mapped security capability: Authentication Mapped feature: Authentication Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 16 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00938 | AUTH_INFO 7 It should not be possible to “unlock” the server using its own key/certificate.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Key and Certificate Handling; Authentication | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_INFO 7 It should not be possible to “unlock” the server using its own key/certificate. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Key and Certificate Handling; Authentication. Architecture view: Security Services. Mapped security capability: Authentication Mapped feature: Authentication Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 16 Classification: Not Applicable Mandatory level: Should Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00939 | AUTH_REQ 165 The server shall verify the client certificate, sent using the verifyCertificateBidirectional subFunction, according to Figure 3.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Data Authenticity and Integrity Verification; Key and Certificate Handling; Authentication | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 165 The server shall verify the client certificate, sent using the verifyCertificateBidirectional subFunction, according to Figure 3. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Key and Certificate Handling; Authentication. Architecture view: Security Services. Mapped security capability: Authentication Mapped feature: Authentication Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 16 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00940 | AUTH_REQ 134 The server shall verify the Signature of the Client certificate using the AUTH-CA EMP entity public key.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Data Authenticity and Integrity Verification; Key and Certificate Handling; Authentication | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 134 The server shall verify the Signature of the Client certificate using the AUTH-CA EMP entity public key. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Key and Certificate Handling; Authentication. Architecture view: Security Services. Mapped security capability: Authentication Mapped feature: Authentication Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 16 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00941 | Internal Page 18 (31) 4.1.1 NodeUID extension If the NodeUID extension is detected, the server shall: AUTH_REQ 166 • Check if the NodeUID of the server is present in the NodeUIDs extension.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Internal Page 18 (31) 4.1.1 NodeUID extension If the NodeUID extension is detected, the server shall: AUTH_REQ 166 • Check if the NodeUID of the server is present in the NodeUIDs extension. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 18 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00942 | AUTH_REQ 9 • If the server NodeUID is not found in the NodeUID extension, the server shall reject the certificate and generate NRC 0x10 (generalReject).Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Key and Certificate Handling; Authentication | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 9 • If the server NodeUID is not found in the NodeUID extension, the server shall reject the certificate and generate NRC 0x10 (generalReject). Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Key and Certificate Handling; Authentication. Architecture view: Security Services. Mapped security capability: Authentication Mapped feature: Authentication Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 18 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00943 | AUTH_REQ 106 If the NodeUID extension is not detected, the operation shall continue as in AUTH_INFO 25 A certificate without NodeUID extension implies that the certificate is applicable for any NodeUID.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Key and Certificate Handling; Authentication | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 106 If the NodeUID extension is not detected, the operation shall continue as in AUTH_INFO 25 A certificate without NodeUID extension implies that the certificate is applicable for any NodeUID. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Key and Certificate Handling; Authentication. Architecture view: Security Services. Mapped security capability: Authentication Mapped feature: Authentication Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 18 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00944 | 4.1.2 ECU-Diagnostic Role extension AUTH_REQ 170 The ECU-Diagnostic role extension shall be included in the client certificate.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Key and Certificate Handling; Cybersecurity Evidence and DIA; Authentication | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 4.1.2 ECU-Diagnostic Role extension AUTH_REQ 170 The ECU-Diagnostic role extension shall be included in the client certificate. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Key and Certificate Handling; Cybersecurity Evidence and DIA; Authentication. Architecture view: Security Services. Mapped security capability: Authentication Mapped feature: Authentication Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 18 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00945 | AUTH_REQ 13 The roles shall correspond to a bit pattern-octet string.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 13 The roles shall correspond to a bit pattern-octet string. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 18 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00946 | AUTH_INFO 8 The interpretation of the roles should follow as the example below: • Role 1 -> 0000 0000 0000 0000 0000 0000 0000 0001 – 00 00 00 01 • Role 32 -> 1000 0000 0000 0000 0000 0000 0000 0000 – 80 00 00 00 • Role 2 and 4 -> 0000 0000 0000 0000 0000 0000 0000 1010 – 00 00 00 0A.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_INFO 8 The interpretation of the roles should follow as the example below: • Role 1 -> 0000 0000 0000 0000 0000 0000 0000 0001 – 00 00 00 01 • Role 32 -> 1000 0000 0000 0000 0000 0000 0000 0000 – 80 00 00 00 • Role 2 and 4 -> 0000 0000 0000 0000 0000 0000 0000 1010 – 00 00 00 0A. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 18 Classification: Not Applicable Mandatory level: Should Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00947 | While the ECU-Diagnostic Role extension specifies the roles assigned to a client, the D-RBACC extension may both grant additional permissions and restrict permissions beyond those derived from the client’s roles.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: While the ECU-Diagnostic Role extension specifies the roles assigned to a client, the D-RBACC extension may both grant additional permissions and restrict permissions beyond those derived from the client’s roles. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Cybersecurity Evidence and DIA. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 18 Classification: Reclassified as Assumption Mandatory level: May Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00948 | AUTH_REQ 14 If D-RBACC extension is detected, the server shall overrule the RBACC with the D-RBACC permissions.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 14 If D-RBACC extension is detected, the server shall overrule the RBACC with the D-RBACC permissions. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 18 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00949 | AUTH_INFO 61 This means that if D-RBACC logic denies/permits certain access, the server shall deny/permit the access regardless of what RBACC logic permits/denies.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Secure Diagnostics and RBAC; Security Logging and Event Handling | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_INFO 61 This means that if D-RBACC logic denies/permits certain access, the server shall deny/permit the access regardless of what RBACC logic permits/denies. Engineering expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Security Logging and Event Handling. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 18 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00950 | Internal Page 19 (31) As part of the certificate verification: AUTH_REQ 135 • The server shall validate the D-RBACC by parsing all its content.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Secure Diagnostics and RBAC; Data Authenticity and Integrity Verification; Key and Certificate Handling; Cybersecurity Evidence and DIA; Authentication | Interface: OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: Internal Page 19 (31) As part of the certificate verification: AUTH_REQ 135 • The server shall validate the D-RBACC by parsing all its content. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Data Authenticity and Integrity Verification; Key and Certificate Handling; Cybersecurity Evidence and DIA; Authentication. Interface view: OEM/Customer Review Interface. Architecture view: Security Services; OEM/Customer Review Interface. Mapped security capability: Authentication Mapped feature: Authentication; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: Security Services; OEM/Customer Review Interface Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 19 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-00951 | If content is invalid, the certificate is invalid and the server shall return a Negative Response Code (NRC) 0x10, indicating generalReject.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Key and Certificate Handling; Certificate handling | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: If content is invalid, the certificate is invalid and the server shall return a Negative Response Code (NRC) 0x10, indicating generalReject. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Key and Certificate Handling; Certificate handling. Architecture view: Security Services. Mapped security capability: Certificate handling Mapped feature: Certificate handling Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 19 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00952 | AUTH_REQ 136 • The server shall verify that the D-RBACC version provided by the client is compatible with the server’s supported D-RBACC version.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Diagnostics and RBAC; Data Authenticity and Integrity Verification | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 136 • The server shall verify that the D-RBACC version provided by the client is compatible with the server’s supported D-RBACC version. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Data Authenticity and Integrity Verification. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 19 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00953 | If non-compliant, the certificate is invalid and the server shall return a Negative Response Code (NRC) 0x10, indicating generalReject.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Key and Certificate Handling; Certificate handling | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: If non-compliant, the certificate is invalid and the server shall return a Negative Response Code (NRC) 0x10, indicating generalReject. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Key and Certificate Handling; Certificate handling. Architecture view: Security Services. Mapped security capability: Certificate handling Mapped feature: Certificate handling Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 19 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00954 | 4.1.4 basicContraints extension AUTH_REQ 42 The basicConstraints extension CA field shall be False.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 4.1.4 basicContraints extension AUTH_REQ 42 The basicConstraints extension CA field shall be False. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 19 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00955 | 4.1.5 Key Usage extension AUTH_REQ 15 The Key Usage extension (RFC 5280) shall be included in the client certificate.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Key and Certificate Handling; Authentication | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 4.1.5 Key Usage extension AUTH_REQ 15 The Key Usage extension (RFC 5280) shall be included in the client certificate. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Key and Certificate Handling; Authentication. Architecture view: Security Services. Mapped security capability: Authentication Mapped feature: Authentication Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 19 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00956 | AUTH_REQ 47 The Key Usage extension shall contain DigitalSignature.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Data Authenticity and Integrity Verification; Key and Certificate Handling; Authentication | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 47 The Key Usage extension shall contain DigitalSignature. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Key and Certificate Handling; Authentication. Architecture view: Security Services. Mapped security capability: Authentication Mapped feature: Authentication Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 19 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00957 | 4.1.6 Extended Key Usage extension AUTH_REQ 95 The Extended Key Usage extension (RFC 5280) shall be included in the client certificate.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Key and Certificate Handling; Authentication | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 4.1.6 Extended Key Usage extension AUTH_REQ 95 The Extended Key Usage extension (RFC 5280) shall be included in the client certificate. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Key and Certificate Handling; Authentication. Architecture view: Security Services. Mapped security capability: Authentication Mapped feature: Authentication Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 19 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00958 | AUTH_REQ 107 The extension ExtendedKeyUsage shall contain clientAuth (1.3.6.1.5.5.7.3.2).Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Key and Certificate Handling | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 107 The extension ExtendedKeyUsage shall contain clientAuth (1.3.6.1.5.5.7.3.2). Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Key and Certificate Handling. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 19 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00959 | 4.1.7 SignatureAlgorithm AUTH_REQ 105 The extension SignatureAlgorithm shall contain ED25519 (1.3.101.112).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Data Authenticity and Integrity Verification | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 4.1.7 SignatureAlgorithm AUTH_REQ 105 The extension SignatureAlgorithm shall contain ED25519 (1.3.101.112). Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Data Authenticity and Integrity Verification. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 19 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00960 | 4.1.8 Certificate Validity Time AUTH_REQ 169 The server shall validate the certificate so that: 𝑛𝑜𝑡𝐵𝑒𝑓𝑜𝑟𝑒 ≤ 𝐶𝑒𝑟𝑡𝑖𝑓𝑖𝑐𝑎𝑡𝑒-𝑡𝑖𝑚𝑒 ≤ 𝑛𝑜𝑡𝐴𝑓𝑡𝑒𝑟 AUTH_INFO 137 The notBefore and notAfter are received as fields in the certificate while Certificate-Time is the EMP entity defined in CVS34.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Key and Certificate Handling; Authentication | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 4.1.8 Certificate Validity Time AUTH_REQ 169 The server shall validate the certificate so that: 𝑛𝑜𝑡𝐵𝑒𝑓𝑜𝑟𝑒 ≤ 𝐶𝑒𝑟𝑡𝑖𝑓𝑖𝑐𝑎𝑡𝑒-𝑡𝑖𝑚𝑒 ≤ 𝑛𝑜𝑡𝐴𝑓𝑡𝑒𝑟 AUTH_INFO 137 The notBefore and notAfter are received as fields in the certificate while Certificate-Time is the EMP entity defined in CVS34. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Key and Certificate Handling; Authentication. Architecture view: Security Services. Mapped security capability: Authentication Mapped feature: Authentication Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 19 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00961 | Internal Page 20 (31) 4.2 State-keeping The server shall invalidate the authentication pending state in the event of: AUTH_REQ 138 • The server is reset (i.e server is power cycled).Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Secure Boot and Application State Control; Key and Certificate Handling; Security Logging and Event Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Internal Page 20 (31) 4.2 State-keeping The server shall invalidate the authentication pending state in the event of: AUTH_REQ 138 • The server is reset (i.e server is power cycled). Engineering expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Engineering interpretation: Security view: Secure Boot and Application State Control; Key and Certificate Handling; Security Logging and Event Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 20 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00962 | AUTH_REQ 156 If a server reset is triggered by a client request (e.g., UDS service 0x11), the server shall send the corresponding response before invalidating the authentication pending state.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control; Key and Certificate Handling | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 156 If a server reset is triggered by a client request (e.g., UDS service 0x11), the server shall send the corresponding response before invalidating the authentication pending state. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control; Key and Certificate Handling. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 20 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00963 | If a client and server have successfully completed the authentication process, the server shall invalidate the authentication state in the event of: AUTH_REQ 16 • The server is reset (i.e server is power cycled).Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Secure Boot and Application State Control; Key and Certificate Handling; Security Logging and Event Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: If a client and server have successfully completed the authentication process, the server shall invalidate the authentication state in the event of: AUTH_REQ 16 • The server is reset (i.e server is power cycled). Engineering expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Engineering interpretation: Security view: Secure Boot and Application State Control; Key and Certificate Handling; Security Logging and Event Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 20 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00964 | AUTH_REQ 157 If a server reset is triggered by a client request (e.g., UDS service 0x11), the server shall send the corresponding response before invalidating the authentication state.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control; Key and Certificate Handling | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 157 If a server reset is triggered by a client request (e.g., UDS service 0x11), the server shall send the corresponding response before invalidating the authentication state. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control; Key and Certificate Handling. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 20 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00965 | The server’s authentication pending state shall contain the minimum of (non-exhaustive list): AUTH_REQ 140 • Client address that issued the authentication request.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Key and Certificate Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: The server’s authentication pending state shall contain the minimum of (non-exhaustive list): AUTH_REQ 140 • Client address that issued the authentication request. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Key and Certificate Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 20 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00966 | The server’s authentication state shall contain the minimum of (non-exhaustive list): AUTH_REQ 21 • SessionKey.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Secure Diagnostics and RBAC; Key and Certificate Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: The server’s authentication state shall contain the minimum of (non-exhaustive list): AUTH_REQ 21 • SessionKey. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Key and Certificate Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 21 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00967 | AUTH_REQ 147 • Client roles (ECU diagnostic Role extension in client’s certificate) AUTH_REQ 148 • Client D-RBACC, if provided in the client’s certificate AUTH_REQ 149 The server shall support only one authentication state.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Key and Certificate Handling; Cybersecurity Evidence and DIA; Authentication | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 147 • Client roles (ECU diagnostic Role extension in client’s certificate) AUTH_REQ 148 • Client D-RBACC, if provided in the client’s certificate AUTH_REQ 149 The server shall support only one authentication state. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Key and Certificate Handling; Cybersecurity Evidence and DIA; Authentication. Architecture view: Security Services. Mapped security capability: Authentication Mapped feature: Authentication Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 21 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00968 | AUTH_REQ 150 The server shall support only one authentication pending state.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Key and Certificate Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 150 The server shall support only one authentication pending state. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Key and Certificate Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 21 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00969 | AUTH_REQ 167 The private keys shall be generated using a CRNG.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Key and Certificate Handling | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 167 The private keys shall be generated using a CRNG. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Key and Certificate Handling. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 22 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00970 | AUTH_REQ 168 The sessionKey shall be generated according to the pseudo code below.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Secure Diagnostics and RBAC; Key and Certificate Handling | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 168 The sessionKey shall be generated according to the pseudo code below. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Key and Certificate Handling. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 22 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00971 | AUTH_REQ 24 The server shall ensure that the sessionKey is exclusively used for the application responsible for communication over securedDataTransmission (CVS32).Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Key and Certificate Handling | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 24 The server shall ensure that the sessionKey is exclusively used for the application responsible for communication over securedDataTransmission (CVS32). Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Key and Certificate Handling. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 22 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00972 | 4.5 CRNG AUTH_REQ 33 Solution for a CRNG shall be according to (CVS150).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: 4.5 CRNG AUTH_REQ 33 Solution for a CRNG shall be according to (CVS150). Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 22 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00973 | Internal Page 23 (31) 4.6 Role Based Access Control AUTH_REQ 25 The server shall always allow the Authentication 0x29 service (ISO 14229-1:2020) regardless of the RBAC logic (CVS151).Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Key and Certificate Handling; Security Logging and Event Handling | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Internal Page 23 (31) 4.6 Role Based Access Control AUTH_REQ 25 The server shall always allow the Authentication 0x29 service (ISO 14229-1:2020) regardless of the RBAC logic (CVS151). Engineering expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Key and Certificate Handling; Security Logging and Event Handling. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 23 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00974 | AUTH_REQ 109 Only Passive time-based de-authentication shall be supported.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Key and Certificate Handling | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 109 Only Passive time-based de-authentication shall be supported. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Key and Certificate Handling. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 23 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00975 | 4.7.1 TimeBasedPassiveDeAuthentication AUTH_REQ 26 The server shall start the timer (A3) after a valid proofOfOwnership has been received.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Key and Certificate Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 4.7.1 TimeBasedPassiveDeAuthentication AUTH_REQ 26 The server shall start the timer (A3) after a valid proofOfOwnership has been received. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Key and Certificate Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 23 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00976 | AUTH_REQ 27 The server shall restart the timer (A3) every time a request is received by the same client.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 27 The server shall restart the timer (A3) every time a request is received by the same client. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 23 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00977 | AUTH_REQ 28 If the A3 timer timeouts before a new request is received (from the same client), the server shall invalidate the authentication state.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Key and Certificate Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 28 If the A3 timer timeouts before a new request is received (from the same client), the server shall invalidate the authentication state. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Key and Certificate Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 23 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00978 | AUTH_REQ 29 The parameter for passive timeout based deAuthenticate shall be decided in the project.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 29 The parameter for passive timeout based deAuthenticate shall be decided in the project. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 23 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00979 | AUTH_INFO 14 The A3 timer differs from S3 timer in terms of expected behavior during timeout and should not be implemented as a single timer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: AUTH_INFO 14 The A3 timer differs from S3 timer in terms of expected behavior during timeout and should not be implemented as a single timer. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 23 Classification: Not Applicable Mandatory level: Should Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00980 | Internal Page 24 (31) 4.8 Authentication delay timer AUTH_INFO 38 The delay timer represents the required minimum time between verifyCertificateBidirectional request attempts.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Data Authenticity and Integrity Verification; Key and Certificate Handling | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Internal Page 24 (31) 4.8 Authentication delay timer AUTH_INFO 38 The delay timer represents the required minimum time between verifyCertificateBidirectional request attempts. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Key and Certificate Handling. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 24 Classification: Not Applicable Mandatory level: Must Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00981 | AUTH_REQ 133 The delay timer shall be set to 1 second.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 133 The delay timer shall be set to 1 second. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 24 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00982 | AUTH_REQ 151 If the delay timer is not running, the server shall start it as part of verifyCertificateBidirectional request.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Data Authenticity and Integrity Verification; Key and Certificate Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 151 If the delay timer is not running, the server shall start it as part of verifyCertificateBidirectional request. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Key and Certificate Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 24 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00983 | AUTH_REQ 152 If the server can determine that a delay is not running after reset, it shall accept a subsequent authentication request without any delay.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Boot and Application State Control; Secure Communication and Boundary Control; Key and Certificate Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 152 If the server can determine that a delay is not running after reset, it shall accept a subsequent authentication request without any delay. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Boot and Application State Control; Secure Communication and Boundary Control; Key and Certificate Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 24 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00984 | AUTH_REQ 153 If the server cannot determine that a delay is not running after reset, it shall not accept a subsequent authentication request without any delay.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Boot and Application State Control; Secure Communication and Boundary Control; Key and Certificate Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 153 If the server cannot determine that a delay is not running after reset, it shall not accept a subsequent authentication request without any delay. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Boot and Application State Control; Secure Communication and Boundary Control; Key and Certificate Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 24 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00985 | AUTH_REQ 154 The Authentication completion timer shall be set to 1 minute.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Key and Certificate Handling | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: AUTH_REQ 154 The Authentication completion timer shall be set to 1 minute. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Key and Certificate Handling. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 24 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00986 | Internal Page 29 (31) Annex B (informative) Change history Release Date Changes The whole standard has been reworked and shall be read in its entirety.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Internal Page 29 (31) Annex B (informative) Change history Release Date Changes The whole standard has been reworked and shall be read in its entirety. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS31.pdf Source Markdown: converted/markdown-cleaned/CVS31.md Page reference: page 29 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00987 | The User shall apply the latest version of this CVS32.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: System Core Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The User shall apply the latest version of this CVS32. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: System Core Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 1 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00988 | Internal Page 2 (29) Foreword This CVS32 contains requirement specification for TRATON GROUP and may be used by all within TRATON Group, if applicable.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: None Status: Missing security feature, interface, architecture | Low Not needed | DetailsFull requirement statement: Internal Page 2 (29) Foreword This CVS32 contains requirement specification for TRATON GROUP and may be used by all within TRATON Group, if applicable. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Traceability needs review before this requirement can be used as design evidence. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 2 Classification: Needs Manual Markdown Correction Mandatory level: May Customer clarification status: Not needed Human review status: Needed Recommended action: Review extracted Markdown wording and confirm baseline treatment. |
| REQ-AUTO-00989 | Any review of CVS32 shall only be done in agreement with the involved departments stated in the table on the first page under section “Technical responsibility”.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Compliance Process Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: Any review of CVS32 shall only be done in agreement with the involved departments stated in the table on the first page under section “Technical responsibility”. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Compliance Process. Mapped security capability: None Mapped feature: System behavior Mapped interface: None Mapped architecture element: Compliance Process Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 2 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00990 | • Affiliate means any legal entity that directly or indirectly controls, is controlled by, or is commonly controlled with TRATON SE, it is being understood that “control” shall mean ownership of at least 50% of the voting rights or interest in the issued share capital, including for the avoidance of doubt any branch.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Backend and IT Systems Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: • Affiliate means any legal entity that directly or indirectly controls, is controlled by, or is commonly controlled with TRATON SE, it is being understood that “control” shall mean ownership of at least 50% of the voting rights or interest in the issued share capital, including for the avoidance of doubt any branch. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 2 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00991 | The keywords “shall”, “should”, “must” and so forth are used in this document and are to be interpreted in accordance with “Key words for use in RFCs to Indicate Requirement Levels” [10].Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Key and Certificate Handling; Key management | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: The keywords “shall”, “should”, “must” and so forth are used in this document and are to be interpreted in accordance with “Key words for use in RFCs to Indicate Requirement Levels” [10]. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Key and Certificate Handling; Key management. Architecture view: Security Services. Mapped security capability: Key management Mapped feature: Key management Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 4 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00992 | Internal Page 6 (29) 2 General SDT_REQ 1 The implementation of SDT (SecuredDataTransmission) shall follow the information provided in ISO14229-1 [1] chapter 16: Security sub-layer and in the TRATON Specification on Unified diagnostic Services (UDS) requirements [8].Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Internal Page 6 (29) 2 General SDT_REQ 1 The implementation of SDT (SecuredDataTransmission) shall follow the information provided in ISO14229-1 [1] chapter 16: Security sub-layer and in the TRATON Specification on Unified diagnostic Services (UDS) requirements [8]. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security. Architecture view: Security Services. Mapped security capability: Diagnostic security Mapped feature: Secure communication and freshness protection; Diagnostic security Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 6 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00993 | SDT_REQ 2 Whenever a requirement in this document deviates from requirements in ISO14229-1 [1] the requirements of this document shall take precedence.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 2 Whenever a requirement in this document deviates from requirements in ISO14229-1 [1] the requirements of this document shall take precedence. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior; Secure communication and freshness protection Mapped interface: None Mapped architecture element: System Core Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 6 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00994 | one diagnostic server in the boot-loader and one in the application, shall support SDT in all execution states.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: one diagnostic server in the boot-loader and one in the application, shall support SDT in all execution states. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Boot and Application State Control; Secure Communication and Boundary Control; Cybersecurity Evidence and DIA; Diagnostic security. Architecture view: Security Services. Mapped security capability: Diagnostic security Mapped feature: Secure communication and freshness protection; Diagnostic security Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 6 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00995 | SDT_REQ 4 The SDT server shall use the diagnostic tester address of the SDT client to identify the authentication state and hence the SecuredDataTransmissionKey.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Key and Certificate Handling; Cybersecurity Evidence and DIA; Authentication | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 4 The SDT server shall use the diagnostic tester address of the SDT client to identify the authentication state and hence the SecuredDataTransmissionKey. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control; Key and Certificate Handling; Cybersecurity Evidence and DIA; Authentication. Architecture view: Security Services. Mapped security capability: Authentication Mapped feature: Secure communication and freshness protection; Authentication Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 6 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00996 | (There may be more than one authentication state).Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Key and Certificate Handling | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: (There may be more than one authentication state). Engineering expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Engineering interpretation: Security view: Key and Certificate Handling. Mapped security capability: None Mapped feature: None Mapped interface: None Mapped architecture element: None Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 6 Classification: Reclassified as Assumption Mandatory level: May Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-00997 | SDT_REQ 5 The server shall not allow an SDT message with service 0x84 as the application layer service (service 0x84 encapsulated inside another service 0x84).Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 5 The server shall not allow an SDT message with service 0x84 as the application layer service (service 0x84 encapsulated inside another service 0x84). Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; Secure communication and freshness protection Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 7 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00998 | The server shall respond with application layer NRC 0x39, i.e.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | None | Interface: None Architecture: Application Software Status: Missing security feature, interface | Medium Not needed | DetailsFull requirement statement: The server shall respond with application layer NRC 0x39, i.e. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 7 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-00999 | the response shall be a properly formatted SDT positive 3 ISO 14299-1:2020 Clarifications and Deviations 3.1 Anti-replay Protection and Transaction Coherency SDT_INFO 5 Anti-replay protection for SDT messages is provided by the ANTIREPLAYCNT protocol element.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: the response shall be a properly formatted SDT positive 3 ISO 14299-1:2020 Clarifications and Deviations 3.1 Anti-replay Protection and Transaction Coherency SDT_INFO 5 Anti-replay protection for SDT messages is provided by the ANTIREPLAYCNT protocol element. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces; Secure communication and freshness protection Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 7 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-01000 | SDT_REQ 6 Both client and server shall maintain instances of the state variables PREQARC and PRESARC.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 6 Both client and server shall maintain instances of the state variables PREQARC and PRESARC. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Secure communication and freshness protection; Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 7 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01001 | SDT_REQ 7 At construction of an SDT request, the client shall increment PREQARC by one (1) and populate the ANTIREPLAYCNT protocol element with the resulting value.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: SDT_REQ 7 At construction of an SDT request, the client shall increment PREQARC by one (1) and populate the ANTIREPLAYCNT protocol element with the resulting value. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces; Secure communication and freshness protection Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 7 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-01002 | SDT_REQ 8 At reception of an SDT request, the server shall verify that the value of the ANTIREPLAYCNT protocol element is greater than PREQARC, and if the message can be otherwise verified, update PREQARC to reflect the new value, i.e.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Secure Software Update; Data Authenticity and Integrity Verification; Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 8 At reception of an SDT request, the server shall verify that the value of the ANTIREPLAYCNT protocol element is greater than PREQARC, and if the message can be otherwise verified, update PREQARC to reflect the new value, i.e. Engineering expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Engineering interpretation: Security view: Secure Software Update; Data Authenticity and Integrity Verification; Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Secure communication and freshness protection; Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 7 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01003 | SDT_REQ 9 At construction of an SDT response, the server shall increment PRESARC by one (1) and populate the ANTIREPLAYCNT protocol element with the resulting value.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 9 At construction of an SDT response, the server shall increment PRESARC by one (1) and populate the ANTIREPLAYCNT protocol element with the resulting value. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Secure communication and freshness protection; Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 7 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01004 | SDT_REQ 10 At reception of an SDT response, the client shall verify that the value of the ANTIREPLAYCNT protocol element is greater than PRESARC, and if the message can be otherwise verified, update PRESARC to reflect the new value, i.e.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Secure Software Update; Data Authenticity and Integrity Verification; Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: SDT_REQ 10 At reception of an SDT response, the client shall verify that the value of the ANTIREPLAYCNT protocol element is greater than PRESARC, and if the message can be otherwise verified, update PRESARC to reflect the new value, i.e. Engineering expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Engineering interpretation: Security view: Secure Software Update; Data Authenticity and Integrity Verification; Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces; Secure communication and freshness protection Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 7 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-01005 | Internal Page 8 (29) SDT_REQ 11 The client should populate the ANTIREPLAYCNT protocol element of the first request of an SDT sequence with the value zero (0), and set PREQARC accordingly.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: Internal Page 8 (29) SDT_REQ 11 The client should populate the ANTIREPLAYCNT protocol element of the first request of an SDT sequence with the value zero (0), and set PREQARC accordingly. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces; Secure communication and freshness protection Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 8 Classification: Not Applicable Mandatory level: Should Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-01006 | SDT_REQ 12 The server should populate the ANTIREPLAYCNT protocol element of the first response of an SDT sequence with the value zero (0), and set PRESARC accordingly.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 12 The server should populate the ANTIREPLAYCNT protocol element of the first response of an SDT sequence with the value zero (0), and set PRESARC accordingly. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Secure communication and freshness protection; Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 8 Classification: Not Applicable Mandatory level: Should Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01007 | SDT_REQ 13 If either PREQARC or PRESARC reaches the maximum value 65535 (0xFFFF), the client shall re-authenticate if it wishes to send more messages.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 13 If either PREQARC or PRESARC reaches the maximum value 65535 (0xFFFF), the client shall re-authenticate if it wishes to send more messages. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Secure communication and freshness protection; Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 8 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01008 | SDT_REQ 14 The client shall maintain the state variable PREQTAG.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 14 The client shall maintain the state variable PREQTAG. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior; Secure communication and freshness protection Mapped interface: None Mapped architecture element: System Core Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01009 | SDT_REQ 15 The CipherScheme used when constructing an SDT message shall be indicated by the SIGENCRYPT protocol element according to Table 2.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: SDT_REQ 15 The CipherScheme used when constructing an SDT message shall be indicated by the SIGENCRYPT protocol element according to Table 2. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces; Secure communication and freshness protection Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 9 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-01010 | SDT_REQ 16 The CipherSchemes SDT_AEAD_CHACHA20_POLY1305 and SDT_POLY1305 shall be supported.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 16 The CipherSchemes SDT_AEAD_CHACHA20_POLY1305 and SDT_POLY1305 shall be supported. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior; Secure communication and freshness protection Mapped interface: None Mapped architecture element: System Core Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01011 | SDT_REQ 17 At SDT message reception, the recipient shall verify/decrypt the message using the CipherScheme indicated by the SIGENCRYPT protocol element.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Data Authenticity and Integrity Verification; Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: SDT_REQ 17 At SDT message reception, the recipient shall verify/decrypt the message using the CipherScheme indicated by the SIGENCRYPT protocol element. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces; Secure communication and freshness protection Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-01012 | SDT_REQ 18 In case of a positive SDT response, the server shall respond to a client request with the same CipherScheme used in the request.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 18 In case of a positive SDT response, the server shall respond to a client request with the same CipherScheme used in the request. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Secure communication and freshness protection; Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 10 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01013 | SDT_REQ 19 The client may alter the CipherScheme between SDT requests within the same SDT sequence.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: SDT_REQ 19 The client may alter the CipherScheme between SDT requests within the same SDT sequence. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Mapped security capability: None Mapped feature: Secure communication and freshness protection Mapped interface: None Mapped architecture element: None Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 10 Classification: Reclassified as Assumption Mandatory level: May Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-01014 | SDT_REQ 20 Client and server should keep state variables that indicate which CipherScheme, and resulting key, was used in the previous SDT transaction.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Secure Communication and Boundary Control; Key and Certificate Handling; Key management | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 20 Client and server should keep state variables that indicate which CipherScheme, and resulting key, was used in the previous SDT transaction. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Secure Communication and Boundary Control; Key and Certificate Handling; Key management. Architecture view: Security Services. Mapped security capability: Key management Mapped feature: Secure communication and freshness protection; Key management Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 10 Classification: Not Applicable Mandatory level: Should Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01015 | SDT_REQ 21 At construction of an SDT request, if SIGENCRYPT is different from PSIGENCRYPT, the client should re-run the KDF, and if and only if the authentication/encryption succeeds, update the state variables PSIGENCRYPT and PKEY with the new values.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Secure Software Update; Secure Communication and Boundary Control; Key and Certificate Handling | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 21 At construction of an SDT request, if SIGENCRYPT is different from PSIGENCRYPT, the client should re-run the KDF, and if and only if the authentication/encryption succeeds, update the state variables PSIGENCRYPT and PKEY with the new values. Engineering expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Engineering interpretation: Security view: Secure Software Update; Secure Communication and Boundary Control; Key and Certificate Handling. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior; Secure communication and freshness protection Mapped interface: None Mapped architecture element: System Core Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 10 Classification: Not Applicable Mandatory level: Should Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01016 | SDT_REQ 22 At reception of an SDT request, if SIGENCRYPT is different from PSIGENCRYPT, the server should re-run the KDF, and if and only if the verification/decryption succeeds, update the state variables PSIGENCRYPT and PKEY with the new values.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Secure Software Update; Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Key and Certificate Handling; Cybersecurity Evidence and DIA | Interface: OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: SDT_REQ 22 At reception of an SDT request, if SIGENCRYPT is different from PSIGENCRYPT, the server should re-run the KDF, and if and only if the verification/decryption succeeds, update the state variables PSIGENCRYPT and PKEY with the new values. Engineering expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Engineering interpretation: Security view: Secure Software Update; Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Key and Certificate Handling; Cybersecurity Evidence and DIA. Interface view: OEM/Customer Review Interface. Architecture view: Backend and IT Systems; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Secure communication and freshness protection; Backend and IT integration; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: Backend and IT Systems; OEM/Customer Review Interface Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 10 Classification: Not Applicable Mandatory level: Should Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-01017 | Client Server PREQARC = X PREQTAG=TAG_X PSIGENCRYPT=3 PKEY=p..p Check: ANTIREPLAYCNT > PREQARC SIGENCRYPT != PSIGENCRYPT: KDF(..) -> r..r decrypt(data, TAG_X+1)->ok Check: ANTIREPLAYCNT > PRESARC decrypt(data||PREQTAG, TAG_Y+1)->ok PRESARC = Y+1 PRESARC = Y+1 PREQARC = X PSIGENCRYPT=3 PKEY=p..p encrypt(data)->TAG_X+1 encrypt(data||TAG_X+1)->TAG_Y+1 S1 S2 S3 C1 C2 C3 SIGENCRYPT != PSIGENCRYPT: KDF(..) -> r..r Figure 4 – Change of CipherScheme mid sequence 3.2.1 HKDF Key Derivation SDT_REQ 23 Client and server shall support the HKDF [2] key derivation function using HMAC-SHA512 [3].Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Key and Certificate Handling; Key management | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Client Server PREQARC = X PREQTAG=TAG_X PSIGENCRYPT=3 PKEY=p..p Check: ANTIREPLAYCNT > PREQARC SIGENCRYPT != PSIGENCRYPT: KDF(..) -> r..r decrypt(data, TAG_X+1)->ok Check: ANTIREPLAYCNT > PRESARC decrypt(data||PREQTAG, TAG_Y+1)->ok PRESARC = Y+1 PRESARC = Y+1 PREQARC = X PSIGENCRYPT=3 PKEY=p..p encrypt(data)->TAG_X+1 encrypt(data||TAG_X+1)->TAG_Y+1 S1 S2 S3 C1 C2 C3 SIGENCRYPT != PSIGENCRYPT: KDF(..) -> r..r Figure 4 – Change of CipherScheme mid sequence 3.2.1 HKDF Key Derivation SDT_REQ 23 Client and server shall support the HKDF [2] key derivation function using HMAC-SHA512 [3]. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Key and Certificate Handling; Key management. Architecture view: Security Services. Mapped security capability: Key management Mapped feature: Secure communication and freshness protection; Key management Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01018 | 𝐻𝐾𝐷𝐹(𝑖𝑘𝑚, 𝑠𝑎𝑙𝑡, 𝑖𝑛𝑓𝑜, 𝐿) → 𝑜𝑘𝑚 SDT_REQ 24 ikm : The ikm argument to the HKDF function shall be the octet string containing the SecuredDataTransmissionKey from the service 0x29 authentication state.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Secure Communication and Boundary Control; Key and Certificate Handling | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 𝐻𝐾𝐷𝐹(𝑖𝑘𝑚, 𝑠𝑎𝑙𝑡, 𝑖𝑛𝑓𝑜, 𝐿) → 𝑜𝑘𝑚 SDT_REQ 24 ikm : The ikm argument to the HKDF function shall be the octet string containing the SecuredDataTransmissionKey from the service 0x29 authentication state. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Secure Communication and Boundary Control; Key and Certificate Handling. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; Secure communication and freshness protection Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01019 | SDT_REQ 25 salt: The salt argument to the HKDF function shall be set as the zero length octet string (null).Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 25 salt: The salt argument to the HKDF function shall be set as the zero length octet string (null). Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; Secure communication and freshness protection Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01020 | SDT_REQ 26 info: The info argument to the HKDF function shall be set as the concatenation of the “SDT_0x84_KEY” octet string and the CipherScheme identifier.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Secure Communication and Boundary Control; Key and Certificate Handling | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 26 info: The info argument to the HKDF function shall be set as the concatenation of the “SDT_0x84_KEY” octet string and the CipherScheme identifier. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Secure Communication and Boundary Control; Key and Certificate Handling. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; Secure communication and freshness protection Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 11 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01021 | SDT_REQ 27 The L argument to the HKDF function shall be set to 64.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 27 The L argument to the HKDF function shall be set to 64. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; Secure communication and freshness protection Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01022 | SDT_REQ 28 Octets 0-31 of the okm shall be used as key by the client to encrypt, and the server to decrypt, the request.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Secure Communication and Boundary Control; Key and Certificate Handling; Key management | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 28 Octets 0-31 of the okm shall be used as key by the client to encrypt, and the server to decrypt, the request. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Secure Communication and Boundary Control; Key and Certificate Handling; Key management. Architecture view: Security Services. Mapped security capability: Key management Mapped feature: Secure communication and freshness protection; Key management Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01023 | SDT_REQ 29 Octets 32-63 of the okm shall be used as key by the server to encrypt, and the client to decrypt, the response.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Secure Communication and Boundary Control; Key and Certificate Handling; Key management | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 29 Octets 32-63 of the okm shall be used as key by the server to encrypt, and the client to decrypt, the response. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Secure Communication and Boundary Control; Key and Certificate Handling; Key management. Architecture view: Security Services. Mapped security capability: Key management Mapped feature: Secure communication and freshness protection; Key management Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01024 | Figure 5 – Use of HKDF output key material (okm) with SDT_CHACHA20_POLY1305 In subsequent sections (3.2.2.1 and 3.2.2.2) the following requirements shall be met: SDT_REQ 30 𝐾: The 𝐾 argument shall be the key octet string of 32 octets.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Secure Communication and Boundary Control; Key and Certificate Handling; Key management | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Figure 5 – Use of HKDF output key material (okm) with SDT_CHACHA20_POLY1305 In subsequent sections (3.2.2.1 and 3.2.2.2) the following requirements shall be met: SDT_REQ 30 𝐾: The 𝐾 argument shall be the key octet string of 32 octets. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Secure Communication and Boundary Control; Key and Certificate Handling; Key management. Architecture view: Security Services. Mapped security capability: Key management Mapped feature: Secure communication and freshness protection; Key management Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01025 | SDT_REQ 31 𝑁: The 𝑁 shall be an octet string of length 12, constructed as follows:the first 10 octets shall be set to 6E6F6E73656E73652121, and - the remaining 2 octets shall be ANTIREPLAYCNT.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 31 𝑁: The 𝑁 shall be an octet string of length 12, constructed as follows: - the first 10 octets shall be set to 6E6F6E73656E73652121, and - the remaining 2 octets shall be ANTIREPLAYCNT. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior; Secure communication and freshness protection Mapped interface: None Mapped architecture element: System Core Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01026 | SDT_REQ 32 𝑃: The 𝑃 (Plaintext) argument shall be the octet string that is the concatenation of the INTMSGREQID and SRVSPECPARAM.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 32 𝑃: The 𝑃 (Plaintext) argument shall be the octet string that is the concatenation of the INTMSGREQID and SRVSPECPARAM. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior; Secure communication and freshness protection Mapped interface: None Mapped architecture element: System Core Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01027 | SDT_REQ 33 𝐶: When injected into, or extracted from an SDT message, the first octet of 𝐶 shall correspond to INTMSGREQID, and the remaining octets to SRVSPECPARAM.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: SDT_REQ 33 𝐶: When injected into, or extracted from an SDT message, the first octet of 𝐶 shall correspond to INTMSGREQID, and the remaining octets to SRVSPECPARAM. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces; Secure communication and freshness protection Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 12 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-01028 | Internal Page 13 (29) 3.2.2.1 Client Encryption/Decryption 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑒𝑛𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴, 𝑃) → 𝐶, 𝑇𝐴𝐺 SDT_REQ 34 The client shall encrypt and authenticate the SDT request with the 𝐴 argument set to the concatenated octet string comprised of the SDT, APAR, SIGENCRYPT, SIGLEN and ANTIREPLAYCNT protocol elements.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control; Authentication | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Internal Page 13 (29) 3.2.2.1 Client Encryption/Decryption 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑒𝑛𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴, 𝑃) → 𝐶, 𝑇𝐴𝐺 SDT_REQ 34 The client shall encrypt and authenticate the SDT request with the 𝐴 argument set to the concatenated octet string comprised of the SDT, APAR, SIGENCRYPT, SIGLEN and ANTIREPLAYCNT protocol elements. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control; Authentication. Architecture view: Security Services. Mapped security capability: Authentication Mapped feature: Secure communication and freshness protection; Authentication Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 13 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01029 | SDT_REQ 35 The client shall populate the APAR protocol element in the request so that bits 0, 4, 5 and 6 are set to true.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: SDT_REQ 35 The client shall populate the APAR protocol element in the request so that bits 0, 4, 5 and 6 are set to true. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces; Secure communication and freshness protection Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 13 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-01030 | SDT_REQ 36 The client shall populate the SIGLEN protocol element in the request with 16 (0x0010).Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: SDT_REQ 36 The client shall populate the SIGLEN protocol element in the request with 16 (0x0010). Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces; Secure communication and freshness protection Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 13 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-01031 | SDT_REQ 37 The client shall populate the SIGMACBYTE protocol element in the request with 𝑇𝐴𝐺.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Data Authenticity and Integrity Verification; Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: SDT_REQ 37 The client shall populate the SIGMACBYTE protocol element in the request with 𝑇𝐴𝐺. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces; Secure communication and freshness protection Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 13 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-01032 | SDT_REQ 38 The client shall store 𝑇𝐴𝐺 in its state variable PREQTAG.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 38 The client shall store 𝑇𝐴𝐺 in its state variable PREQTAG. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior; Secure communication and freshness protection Mapped interface: None Mapped architecture element: System Core Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 13 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01033 | 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑑𝑒𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴, 𝐶, 𝑇𝐴𝐺) → 𝑜𝑘/𝑛𝑜𝑘, 𝑃 The client shall decrypt and verify the SDT response with: SDT_REQ 39 the 𝐴 argument set to the concatenated octet string comprised of the SDTPR, APAR, SIGENCRYPT, SIGLEN, ANTIREPLAYCNT protocol elements of the response and the value stored in the state variable PREQTAG.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Data Authenticity and Integrity Verification; Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑑𝑒𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴, 𝐶, 𝑇𝐴𝐺) → 𝑜𝑘/𝑛𝑜𝑘, 𝑃 The client shall decrypt and verify the SDT response with: SDT_REQ 39 the 𝐴 argument set to the concatenated octet string comprised of the SDTPR, APAR, SIGENCRYPT, SIGLEN, ANTIREPLAYCNT protocol elements of the response and the value stored in the state variable PREQTAG. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces; Secure communication and freshness protection Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 13 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-01034 | 3.2.2.2 Server Decryption/Encryption 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑑𝑒𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴, 𝐶, 𝑇𝐴𝐺) → 𝑜𝑘/𝑛𝑜𝑘, 𝑃 SDT_REQ 42 The server shall decrypt and verify the SDT request with the 𝐴 argument set to the concatenated octet string comprised of the SDT, APAR, SIGENCRYPT, SIGLEN and ANTIREPLAYCNT protocol elements.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Data Authenticity and Integrity Verification; Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 3.2.2.2 Server Decryption/Encryption 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑑𝑒𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴, 𝐶, 𝑇𝐴𝐺) → 𝑜𝑘/𝑛𝑜𝑘, 𝑃 SDT_REQ 42 The server shall decrypt and verify the SDT request with the 𝐴 argument set to the concatenated octet string comprised of the SDT, APAR, SIGENCRYPT, SIGLEN and ANTIREPLAYCNT protocol elements. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Secure communication and freshness protection; Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 13 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01035 | 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑒𝑛𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴, 𝑃) → 𝐶, 𝑇𝐴𝐺 The server shall encrypt and authenticate the SDT response with: SDT_REQ 44 the 𝐴 argument set to the concatenated octet string comprised of the SDTPR, APAR, SIGENCRYPT, SIGLEN and ANTIREPLAYCNT protocol elements of the response and the octet string carried by the SIGMACBYTE protocol element of the corresponding request.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Authentication | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑒𝑛𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴, 𝑃) → 𝐶, 𝑇𝐴𝐺 The server shall encrypt and authenticate the SDT response with: SDT_REQ 44 the 𝐴 argument set to the concatenated octet string comprised of the SDTPR, APAR, SIGENCRYPT, SIGLEN and ANTIREPLAYCNT protocol elements of the response and the octet string carried by the SIGMACBYTE protocol element of the corresponding request. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Authentication. Architecture view: Security Services. Mapped security capability: Authentication Mapped feature: Secure communication and freshness protection; Authentication Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 13 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01036 | SDT_REQ 46 The server shall populate the APAR protocol element in the response so that bits 4 and 5 are set to true.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 46 The server shall populate the APAR protocol element in the response so that bits 4 and 5 are set to true. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Secure communication and freshness protection; Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 13 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01037 | Internal Page 14 (29) SDT_REQ 47 The server shall populate the SIGLEN protocol element in the request with 16 (0x0010).Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Internal Page 14 (29) SDT_REQ 47 The server shall populate the SIGLEN protocol element in the request with 16 (0x0010). Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Secure communication and freshness protection; Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 14 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01038 | SDT_REQ 48 The server shall populate the SIGMACBYTE protocol element in the request with 𝑇𝐴𝐺.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Data Authenticity and Integrity Verification; Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 48 The server shall populate the SIGMACBYTE protocol element in the request with 𝑇𝐴𝐺. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Secure communication and freshness protection; Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 14 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01039 | one octet, and the rest should go in the SRVSPECPARAM protocol element.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: one octet, and the rest should go in the SRVSPECPARAM protocol element. Engineering expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Engineering interpretation: Security view: Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 14 Classification: Not Applicable Mandatory level: Should Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-01040 | SDT_REQ 49 The L argument to the HKDF function shall be set to 64.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: Application Software Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 49 The L argument to the HKDF function shall be set to 64. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Application Software. Mapped security capability: None Mapped feature: Application software behavior; Secure communication and freshness protection Mapped interface: None Mapped architecture element: Application Software Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 15 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01041 | SDT_REQ 50 Octets 0-31 of the okm shall be used as key by the client to authenticate, and the server to verify, the request.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Key and Certificate Handling; Authentication | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 50 Octets 0-31 of the okm shall be used as key by the client to authenticate, and the server to verify, the request. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Key and Certificate Handling; Authentication. Architecture view: Security Services. Mapped security capability: Authentication Mapped feature: Secure communication and freshness protection; Authentication Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 15 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01042 | SDT_REQ 51 Octets 32-63 of the okm shall be used as key by the server to authenticate, and the client to verify, the response.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Key and Certificate Handling; Authentication | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 51 Octets 32-63 of the okm shall be used as key by the server to authenticate, and the client to verify, the response. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Key and Certificate Handling; Authentication. Architecture view: Security Services. Mapped security capability: Authentication Mapped feature: Secure communication and freshness protection; Authentication Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 15 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01043 | Figure 7 – Use of HKDF output key material (okm) with SDT_POLY1305 In subsequent sections (3.2.3.1 and 3.2.3.2), the following requirements shall be met: SDT_REQ 52 𝐾: The 𝐾 argument shall be the key octet string of 32 octets.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Secure Communication and Boundary Control; Key and Certificate Handling; Key management | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Figure 7 – Use of HKDF output key material (okm) with SDT_POLY1305 In subsequent sections (3.2.3.1 and 3.2.3.2), the following requirements shall be met: SDT_REQ 52 𝐾: The 𝐾 argument shall be the key octet string of 32 octets. Engineering expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Engineering interpretation: Security view: Secure Communication and Boundary Control; Key and Certificate Handling; Key management. Architecture view: Security Services. Mapped security capability: Key management Mapped feature: Secure communication and freshness protection; Key management Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 15 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01044 | SDT_REQ 91 𝑁: The 𝑁 shall be an octet string of length 12, constructed as follows:the first 10 octets shall be set to 6E6F6E73656E73652121, and - the remaining 2 octets shall be ANTIREPLAYCNT.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 91 𝑁: The 𝑁 shall be an octet string of length 12, constructed as follows: - the first 10 octets shall be set to 6E6F6E73656E73652121, and - the remaining 2 octets shall be ANTIREPLAYCNT. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior; Secure communication and freshness protection Mapped interface: None Mapped architecture element: System Core Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 15 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01045 | Internal Page 16 (29) 3.2.3.1 Client Authentication/Verification 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑎𝑢𝑡ℎ𝑒𝑛𝑡𝑖𝑐𝑎𝑡𝑒(𝐾, 𝑁, 𝐴, 𝑃𝑛𝑢𝑙𝑙) → 𝐶𝑛𝑢𝑙𝑙, 𝑇𝐴𝐺 SDT_REQ 54 The client shall authenticate the SDT request with the 𝐴 argument set to the octet string comprised of all protocol elements of the SDT request, excluding the SIGMACBYTE protocol element.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Key and Certificate Handling; Cybersecurity Evidence and DIA | Interface: External Interfaces; OEM/Customer Review Interface Architecture: External Interfaces; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: Internal Page 16 (29) 3.2.3.1 Client Authentication/Verification 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑎𝑢𝑡ℎ𝑒𝑛𝑡𝑖𝑐𝑎𝑡𝑒(𝐾, 𝑁, 𝐴, 𝑃𝑛𝑢𝑙𝑙) → 𝐶𝑛𝑢𝑙𝑙, 𝑇𝐴𝐺 SDT_REQ 54 The client shall authenticate the SDT request with the 𝐴 argument set to the octet string comprised of all protocol elements of the SDT request, excluding the SIGMACBYTE protocol element. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Key and Certificate Handling; Cybersecurity Evidence and DIA. Interface view: External Interfaces; OEM/Customer Review Interface. Architecture view: External Interfaces; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: External interfaces; Secure communication and freshness protection; Security evidence and traceability Mapped interface: External Interfaces; OEM/Customer Review Interface Mapped architecture element: External Interfaces; OEM/Customer Review Interface Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 16 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-01046 | SDT_REQ 55 The client shall populate the APAR protocol element in the request so that bits 0, 5 and 6 are set to true.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: SDT_REQ 55 The client shall populate the APAR protocol element in the request so that bits 0, 5 and 6 are set to true. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces; Secure communication and freshness protection Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 16 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-01047 | SDT_REQ 56 The client shall populate the SIGLEN protocol element in the request with 16 (0x0010).Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: SDT_REQ 56 The client shall populate the SIGLEN protocol element in the request with 16 (0x0010). Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces; Secure communication and freshness protection Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 16 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-01048 | SDT_REQ 57 The client shall populate the SIGMACBYTE protocol element in the request with 𝑇𝐴𝐺.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Data Authenticity and Integrity Verification; Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: SDT_REQ 57 The client shall populate the SIGMACBYTE protocol element in the request with 𝑇𝐴𝐺. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces; Secure communication and freshness protection Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 16 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-01049 | SDT_REQ 58 The client shall store 𝑇𝐴𝐺 in its state variable PREQTAG.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 58 The client shall store 𝑇𝐴𝐺 in its state variable PREQTAG. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior; Secure communication and freshness protection Mapped interface: None Mapped architecture element: System Core Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 16 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01050 | 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑣𝑒𝑟𝑖𝑓𝑦(𝐾, 𝑁, 𝐴, 𝐶𝑛𝑢𝑙𝑙, 𝑇𝐴𝐺) → ok/nok,𝑃𝑛𝑢𝑙𝑙 SDT_REQ 59 The client shall verify the SDT response with the 𝐴 argument set to the octet string comprised of all protocol elements of the SDT response, excluding the SIGMACBYTE protocol element, concatenated with the octet string stored in the state variable PREQTAG.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Data Authenticity and Integrity Verification; Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑣𝑒𝑟𝑖𝑓𝑦(𝐾, 𝑁, 𝐴, 𝐶𝑛𝑢𝑙𝑙, 𝑇𝐴𝐺) → ok/nok,𝑃𝑛𝑢𝑙𝑙 SDT_REQ 59 The client shall verify the SDT response with the 𝐴 argument set to the octet string comprised of all protocol elements of the SDT response, excluding the SIGMACBYTE protocol element, concatenated with the octet string stored in the state variable PREQTAG. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces; Secure communication and freshness protection Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 16 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-01051 | 3.2.3.2 Server Verification/Authentication 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑣𝑒𝑟𝑖𝑓𝑦(𝐾, 𝑁, 𝐴, 𝐶𝑛𝑢𝑙𝑙, 𝑇𝐴𝐺) → ok/nok,𝑃𝑛𝑢𝑙𝑙 SDT_REQ 61 The server shall verify the SDT request with the 𝐴 argument set to the octet string comprised of all protocol elements of the SDT response, excluding the SIGMACBYTE protocol element.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Key and Certificate Handling; Cybersecurity Evidence and DIA | Interface: OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface Status: Complete | Medium Not needed | DetailsFull requirement statement: 3.2.3.2 Server Verification/Authentication 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑣𝑒𝑟𝑖𝑓𝑦(𝐾, 𝑁, 𝐴, 𝐶𝑛𝑢𝑙𝑙, 𝑇𝐴𝐺) → ok/nok,𝑃𝑛𝑢𝑙𝑙 SDT_REQ 61 The server shall verify the SDT request with the 𝐴 argument set to the octet string comprised of all protocol elements of the SDT response, excluding the SIGMACBYTE protocol element. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Secure Communication and Boundary Control; Key and Certificate Handling; Cybersecurity Evidence and DIA. Interface view: OEM/Customer Review Interface. Architecture view: Backend and IT Systems; OEM/Customer Review Interface. Mapped security capability: None Mapped feature: Secure communication and freshness protection; Backend and IT integration; Security evidence and traceability Mapped interface: OEM/Customer Review Interface Mapped architecture element: Backend and IT Systems; OEM/Customer Review Interface Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 16 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-01052 | 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑎𝑢𝑡ℎ𝑒𝑛𝑡𝑖𝑐𝑎𝑡𝑒(𝐾, 𝑁, 𝐴, 𝑃𝑛𝑢𝑙𝑙) → 𝐶𝑛𝑢𝑙𝑙, 𝑇𝐴𝐺 SDT_REQ 63 The server shall authenticate the SDT response with the 𝐴 argument set to the octet string comprised of all protocol elements of the SDT response, excluding the SIGMACBYTE protocol element, concatenated with the octet string carried by the SIGMACBYTE protocol element of the corresponding request.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Data Authenticity and Integrity Verification; Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑎𝑢𝑡ℎ𝑒𝑛𝑡𝑖𝑐𝑎𝑡𝑒(𝐾, 𝑁, 𝐴, 𝑃𝑛𝑢𝑙𝑙) → 𝐶𝑛𝑢𝑙𝑙, 𝑇𝐴𝐺 SDT_REQ 63 The server shall authenticate the SDT response with the 𝐴 argument set to the octet string comprised of all protocol elements of the SDT response, excluding the SIGMACBYTE protocol element, concatenated with the octet string carried by the SIGMACBYTE protocol element of the corresponding request. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Secure communication and freshness protection; Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 16 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01053 | Internal Page 17 (29) SDT_REQ 64 The server shall populate the APAR protocol element in the response so that bit 5 is set to true.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Internal Page 17 (29) SDT_REQ 64 The server shall populate the APAR protocol element in the response so that bit 5 is set to true. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Secure communication and freshness protection; Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 17 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01054 | SDT_REQ 65 The server shall populate the SIGLEN protocol element in the response with 16 (0x0010).Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 65 The server shall populate the SIGLEN protocol element in the response with 16 (0x0010). Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Secure communication and freshness protection; Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 17 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01055 | SDT_REQ 66 The client shall populate the SIGMACBYTE protocol element in the response with 𝑇𝐴𝐺.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Data Authenticity and Integrity Verification; Secure Communication and Boundary Control | Interface: External Interfaces Architecture: External Interfaces Status: Complete | Medium Not needed | DetailsFull requirement statement: SDT_REQ 66 The client shall populate the SIGMACBYTE protocol element in the response with 𝑇𝐴𝐺. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Secure Communication and Boundary Control. Interface view: External Interfaces. Architecture view: External Interfaces. Mapped security capability: None Mapped feature: External interfaces; Secure communication and freshness protection Mapped interface: External Interfaces Mapped architecture element: External Interfaces Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 17 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Use as mapped evidence in the architecture/security baseline. |
| REQ-AUTO-01056 | The SDT positive response may of course contain an encapsulated negative UDS response.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Secure Diagnostics and RBAC; Secure Communication and Boundary Control | Interface: None Architecture: None Status: Missing interface, architecture | Medium Needed | DetailsFull requirement statement: The SDT positive response may of course contain an encapsulated negative UDS response. Engineering expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Engineering interpretation: Security view: Secure Diagnostics and RBAC; Secure Communication and Boundary Control. Mapped security capability: None Mapped feature: Secure communication and freshness protection Mapped interface: None Mapped architecture element: None Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 18 Classification: Reclassified as Assumption Mandatory level: May Customer clarification status: Needed Human review status: Needed Recommended action: Resolve customer clarification and update mappings before claiming closure. |
| REQ-AUTO-01057 | SDT_REQ 67 Other than the NRCs 0x3A, 0x13 and 0x21, specified by ISO14229-1:2020 [1], the server shall support the NRC 0x34 “authenticationRequired”.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control; Key and Certificate Handling | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 67 Other than the NRCs 0x3A, 0x13 and 0x21, specified by ISO14229-1:2020 [1], the server shall support the NRC 0x34 “authenticationRequired”. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control; Key and Certificate Handling. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Secure communication and freshness protection; Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 18 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01058 | Internal Page 19 (29) Figure 10 – Server's error and state handling SDT_REQ 68 At reception of an SDT request, if the security sub-layer is busy, the server shall respond with an SDT negative response using the NRC 0x21.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control; Secure communication | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Internal Page 19 (29) Figure 10 – Server's error and state handling SDT_REQ 68 At reception of an SDT request, if the security sub-layer is busy, the server shall respond with an SDT negative response using the NRC 0x21. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control; Secure communication. Architecture view: Security Services. Mapped security capability: Secure communication Mapped feature: Secure communication and freshness protection; Cybersecurity requirement handling Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 19 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01059 | SDT_REQ 69 At reception of an SDT request, if the requesting client is unauthenticated, the server shall respond with an SDT negative response using the NRC 0x34.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 69 At reception of an SDT request, if the requesting client is unauthenticated, the server shall respond with an SDT negative response using the NRC 0x34. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Secure communication and freshness protection; Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 19 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01060 | Internal Page 20 (29) SDT_REQ 70 At reception of an SDT request, if the request is too short or otherwise malformed, the server shall respond with an SDT negative response using the NRC 0x13.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Internal Page 20 (29) SDT_REQ 70 At reception of an SDT request, if the request is too short or otherwise malformed, the server shall respond with an SDT negative response using the NRC 0x13. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Secure communication and freshness protection; Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 20 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01061 | SDT_REQ 71 At reception of an SDT request, if ANTIREPLAYCNT ≤ PREQARC, the server shall respond with an SDT negative response using the NRC 0x3A.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 71 At reception of an SDT request, if ANTIREPLAYCNT ≤ PREQARC, the server shall respond with an SDT negative response using the NRC 0x3A. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Secure communication and freshness protection; Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 20 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01062 | SDT_REQ 88 At reception of an SDT request, if PRESARC is exhausted, the server shall respond with an SDT negative response using the NRC 0x3A.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 88 At reception of an SDT request, if PRESARC is exhausted, the server shall respond with an SDT negative response using the NRC 0x3A. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Secure communication and freshness protection; Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 20 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01063 | SDT_REQ 72 At reception of an SDT request, if SIGENCRYPT is not supported, the server shall respond with an SDT negative response using the NRC 0x3A.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 72 At reception of an SDT request, if SIGENCRYPT is not supported, the server shall respond with an SDT negative response using the NRC 0x3A. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Secure communication and freshness protection; Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 20 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01064 | SDT_REQ 73 At reception of an SDT request, if APAR is in conflict with SIGENCRYPT, the server shall respond with an SDT negative response using the NRC 0x3A.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 73 At reception of an SDT request, if APAR is in conflict with SIGENCRYPT, the server shall respond with an SDT negative response using the NRC 0x3A. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Secure communication and freshness protection; Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 20 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01065 | SDT_REQ 74 At reception of an SDT request, if SIGLEN is in conflict with SIGENCRYPT, the server shall respond with an SDT negative response using the NRC 0x3A.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 74 At reception of an SDT request, if SIGLEN is in conflict with SIGENCRYPT, the server shall respond with an SDT negative response using the NRC 0x3A. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Secure communication and freshness protection; Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 20 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01066 | SDT_REQ 75 At reception of an SDT request, if the server fails to verify/decrypt the request, the server shall respond with an SDT negative response using the NRC 0x3A.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Data Authenticity and Integrity Verification; Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 75 At reception of an SDT request, if the server fails to verify/decrypt the request, the server shall respond with an SDT negative response using the NRC 0x3A. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Secure communication and freshness protection; Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 20 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01067 | SDT_REQ 76 The server shall update its state, (set PREQARC to the value received in the ANTIREPLAYCNT protocol element in the SDT request), if and only if it successfully verifies/decrypts the SDT request.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Secure Software Update; Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 76 The server shall update its state, (set PREQARC to the value received in the ANTIREPLAYCNT protocol element in the SDT request), if and only if it successfully verifies/decrypts the SDT request. Engineering expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Engineering interpretation: Security view: Secure Software Update; Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Secure communication and freshness protection; Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 20 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01068 | SDT_REQ 77 The server shall update its state, (increment PRESARC by one (1)), if and only if it can successfully authenticate/encrypt the SDT response (“S3”).Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Secure Software Update; Secure Communication and Boundary Control; Authentication | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 77 The server shall update its state, (increment PRESARC by one (1)), if and only if it can successfully authenticate/encrypt the SDT response (“S3”). Engineering expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Engineering interpretation: Security view: Secure Software Update; Secure Communication and Boundary Control; Authentication. Architecture view: Security Services. Mapped security capability: Authentication Mapped feature: Secure communication and freshness protection; Authentication Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 20 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01069 | SDT_REQ 78 The client shall update its state, (increment PREQARC by one (1), if and only if it can successfully authenticate/encrypt the SDT request (“C2”).Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Secure Software Update; Secure Communication and Boundary Control; Authentication | Interface: None Architecture: Security Services Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 78 The client shall update its state, (increment PREQARC by one (1), if and only if it can successfully authenticate/encrypt the SDT request (“C2”). Engineering expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Engineering interpretation: Security view: Secure Software Update; Secure Communication and Boundary Control; Authentication. Architecture view: Security Services. Mapped security capability: Authentication Mapped feature: Secure communication and freshness protection; Authentication Mapped interface: None Mapped architecture element: Security Services Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 21 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01070 | Internal Page 22 (29) Figure 12 – The client's error and state handling SDT_REQ 79 At reception of an SDT response, if the client is unauthenticated, the client shall discard the SDT_REQ 80 At reception of an SDT response, if the request is too short or otherwise malformed, the client shall discard the response.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Internal Page 22 (29) Figure 12 – The client's error and state handling SDT_REQ 79 At reception of an SDT response, if the client is unauthenticated, the client shall discard the SDT_REQ 80 At reception of an SDT response, if the request is too short or otherwise malformed, the client shall discard the response. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior; Secure communication and freshness protection Mapped interface: None Mapped architecture element: System Core Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 22 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01071 | SDT_REQ 81 At reception of an SDT response, if ANTIREPLAYCNT ≤ PRESARC, the client shall discard theExpectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 81 At reception of an SDT response, if ANTIREPLAYCNT ≤ PRESARC, the client shall discard the Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior; Secure communication and freshness protection Mapped interface: None Mapped architecture element: System Core Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 22 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01072 | Internal Page 23 (29) SDT_REQ 82 At reception of an SDT response, if SIGENCRYPT is not supported, the client shall discard the SDT_REQ 83 At reception of an SDT response, if APAR is in conflict with SIGENCRYPT, the client shall discard the response.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: Internal Page 23 (29) SDT_REQ 82 At reception of an SDT response, if SIGENCRYPT is not supported, the client shall discard the SDT_REQ 83 At reception of an SDT response, if APAR is in conflict with SIGENCRYPT, the client shall discard the response. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior; Secure communication and freshness protection Mapped interface: None Mapped architecture element: System Core Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 23 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01073 | SDT_REQ 84 At reception of an SDT response, if SIGLEN is in conflict with SIGENCRYPT, the client shall discard the response.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 84 At reception of an SDT response, if SIGLEN is in conflict with SIGENCRYPT, the client shall discard the response. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior; Secure communication and freshness protection Mapped interface: None Mapped architecture element: System Core Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 23 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01074 | SDT_REQ 85 At reception of an SDT response, if the client fails to verify/decrypt the response, the client shall discard the response.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Data Authenticity and Integrity Verification; Secure Communication and Boundary Control | Interface: None Architecture: System Core Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 85 At reception of an SDT response, if the client fails to verify/decrypt the response, the client shall discard the response. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Data Authenticity and Integrity Verification; Secure Communication and Boundary Control. Architecture view: System Core. Mapped security capability: None Mapped feature: System behavior; Secure communication and freshness protection Mapped interface: None Mapped architecture element: System Core Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 23 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01075 | SDT_REQ 86 The client shall update its state, (set PRESARC to the value received in the ANTIREPLAYCNT protocol element in the SDT response), if and only if it successfully verifies/decrypts the SDT response (“C3”).Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Secure Software Update; Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 86 The client shall update its state, (set PRESARC to the value received in the ANTIREPLAYCNT protocol element in the SDT response), if and only if it successfully verifies/decrypts the SDT response (“C3”). Engineering expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Engineering interpretation: Security view: Secure Software Update; Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Secure communication and freshness protection; Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 23 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
| REQ-AUTO-01076 | SDT_REQ 87 If the client determines an SDT request to be lost in transit, or, if it receives an SDT negative response with NRC BRR (0x21), the client shall • repeat the request byte for byte and leave state variables unchanged.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Secure Communication and Boundary Control | Interface: None Architecture: Backend and IT Systems Status: Missing interface | Medium Not needed | DetailsFull requirement statement: SDT_REQ 87 If the client determines an SDT request to be lost in transit, or, if it receives an SDT negative response with NRC BRR (0x21), the client shall • repeat the request byte for byte and leave state variables unchanged. Engineering expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Engineering interpretation: Security view: Secure Communication and Boundary Control. Architecture view: Backend and IT Systems. Mapped security capability: None Mapped feature: Secure communication and freshness protection; Backend and IT integration Mapped interface: None Mapped architecture element: Backend and IT Systems Source PDF: CVS32.pdf Source Markdown: converted/markdown-cleaned/CVS32.md Page reference: page 23 Classification: Not Applicable Mandatory level: Shall Customer clarification status: Not needed Human review status: Not needed Recommended action: Complete missing traceability links. |
Traceability Gap Summary
This table is horizontally scrollable. Use the bottom scrollbar to view all columns.
| Gap Type | Count | Example Requirement IDs | Recommended Action |
|---|---|---|---|
| Missing Security Feature Mapping | 306 | REQ-AUTO-00004; REQ_SEC_0040; REQ-AUTO-00021; REQ-AUTO-00028; REQ_SEC_0028; REQ_SEC_0029; REQ_SEC_0006; REQ-AUTO-00047 | Map requirement to a security feature or mark not security-relevant. |
| Missing Interface Mapping | 895 | REQ_SEC_0022; REQ-AUTO-00009; REQ_SEC_0023; REQ-AUTO-00011; REQ_SEC_0040; REQ_SEC_0041; REQ_SEC_0010; REQ_SEC_0012 | Confirm affected interface or mark as non-interface evidence. |
| Missing Architecture Mapping | 107 | REQ_SEC_0040; REQ_SEC_0041; req-6.3; Req.ID-Description-6.22.1; REQ-AUTO-00171; REQ-AUTO-00190; REQ-AUTO-00246; REQ-AUTO-00249 | Map to architecture element. |
| Customer Clarification Needed | 64 | REQ-AUTO-00006; REQ_SEC_0040; REQ_SEC_0041; req-6.3; REQ-AUTO-00146; Req.ID-Description-6.22.1; REQ-AUTO-00175; REQ-AUTO-00190 | Resolve customer clarification. |
| Human Review Needed | 117 | REQ-AUTO-00006; REQ_SEC_0040; REQ_SEC_0041; req-6.3; REQ-AUTO-00146; Req.ID-Description-6.22.1; REQ-AUTO-00171; REQ-AUTO-00175 | Review Markdown extraction and baseline status. |
| Low Confidence | 56 | REQ-AUTO-00171; REQ-AUTO-00249; REQ-AUTO-00298; REQ-AUTO-00485; REQ_UDS-0003; REQ_UDS-0004; REQ_UDS-0006; REQ_UDS-0007 | Review source wording and confidence. |
Detailed Evidence
Requirements register markdown
Requirements Evidence Register
Executive Summary
- Total requirements: 1076
- Active requirements: 1047
- Security-relevant mappings: 770
- Customer clarification needed: 64
Traceability Gap Summary
| Gap Type | Count | Example Requirement IDs | Recommended Action |
|---|---|---|---|
| Missing Security Feature Mapping | 306 | REQ-AUTO-00004; REQ_SEC_0040; REQ-AUTO-00021; REQ-AUTO-00028; REQ_SEC_0028; REQ_SEC_0029; REQ_SEC_0006; REQ-AUTO-00047 | Map requirement to a security feature or mark not security-relevant. |
| Missing Interface Mapping | 895 | REQ_SEC_0022; REQ-AUTO-00009; REQ_SEC_0023; REQ-AUTO-00011; REQ_SEC_0040; REQ_SEC_0041; REQ_SEC_0010; REQ_SEC_0012 | Confirm affected interface or mark as non-interface evidence. |
| Missing Architecture Mapping | 107 | REQ_SEC_0040; REQ_SEC_0041; req-6.3; Req.ID-Description-6.22.1; REQ-AUTO-00171; REQ-AUTO-00190; REQ-AUTO-00246; REQ-AUTO-00249 | Map to architecture element. |
| Customer Clarification Needed | 64 | REQ-AUTO-00006; REQ_SEC_0040; REQ_SEC_0041; req-6.3; REQ-AUTO-00146; Req.ID-Description-6.22.1; REQ-AUTO-00175; REQ-AUTO-00190 | Resolve customer clarification. |
| Human Review Needed | 117 | REQ-AUTO-00006; REQ_SEC_0040; REQ_SEC_0041; req-6.3; REQ-AUTO-00146; Req.ID-Description-6.22.1; REQ-AUTO-00171; REQ-AUTO-00175 | Review Markdown extraction and baseline status. |
| Low Confidence | 56 | REQ-AUTO-00171; REQ-AUTO-00249; REQ-AUTO-00298; REQ-AUTO-00485; REQ_UDS-0003; REQ_UDS-0004; REQ_UDS-0006; REQ_UDS-0007 | Review source wording and confidence. |
Register Columns
| Field | Meaning |
|---|---|
| expectation_comment | Concise engineering expectation derived from requirement text and mappings. |
| mapped_security_feature | Explicit traceability where available, otherwise conservative keyword inference. |
| traceability_status | Complete only when security feature, interface and architecture links are present. |