Customer Proposal Package
Product and cybersecurity architecture understanding package generated from Markdown-derived requirements.
Executive Takeaway
This package is the customer-facing requirement disposition register. It gives a supplier proposal per requirement and preserves open customer actions where scope, ownership, diagnostics, update, PKI, or evidence assumptions are unresolved.
- Review supplier position and proposal text before customer release.
- Rows with open-point IDs need customer decisions before they can become agreement baseline.
Search and Filters
Customer Requirement Proposal Package
This table is horizontally scrollable. Use the bottom scrollbar to view all columns.
| Requirement ID | Requirement / Short Title | Source Document | Document Section | Supplier Position | Supplier Proposal | Customer Action Needed | Open Point | Security Capability | Interface | Estimation Impact | Customer Decision | Details |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| REQ-AUTO-00001 | The cybersecurity concept shall describe the scope of the risk analysis, risks that were iden...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. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 3 | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm or correct the stated supplier assumption. | - | Cybersecurity requirement handling | OEM/Customer Review Interface | High | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 3 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Cybersecurity requirement handling | Interface: OEM/Customer Review Interface | SSR: SSR-CON-001 |
| REQ_SEC_0001 | Cybersecurity methods and strategies REQ_SEC_0001 The supplier shall provide documentation de...Cybersecurity methods and strategies REQ_SEC_0001 The supplier shall provide documentation describing their strategies and methods for working with embedded systems cybersecurity. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 5 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | Cybersecurity requirement handling | OEM/Customer Review Interface | High | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 5 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Cybersecurity requirement handling | Interface: OEM/Customer Review Interface | SSR: SSR-CON-001 |
| REQ_SEC_0002 | Risk assessment REQ_SEC_0002 The supplier shall perform risk assessment based on a threat and...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. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 5 | Accept with Assumption | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Confirm or correct the stated supplier assumption. | - | Vulnerability management | OEM/Customer Review Interface | High | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 5 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Vulnerability management | Interface: OEM/Customer Review Interface | SSR: SSR-VIH-001 |
| REQ-AUTO-00004 | Method and scope shall be proposed to and approved by the vehicle manufacturer.Method and scope shall be proposed to and approved by the vehicle manufacturer. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 5 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 5 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-001 |
| REQ-AUTO-00005 | Documentation on the method and results shall be provided to the vehicle manufacturer.Documentation on the method and results shall be provided to the vehicle manufacturer. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 5 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 5 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-001 |
| REQ-AUTO-00006 | Note: The vehicle manufacturer and supplier shall collaboratively define the context of the s...Note: The vehicle manufacturer and supplier shall collaboratively define the context of the system or function to enable the supplier performing the risk assessment. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 5 | Needs Customer Clarification | Needs customer clarification. The requirement implies customer-owned infrastructure, approval, or a responsibility split that is not yet available. | Scope and responsibility for each listed requirement. | OP-011 | None | OEM/Customer Review Interface | Unknown | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 5 Supplier rationale Flagged customer_clarification_needed=yes during extraction. Implementation approach Hold implementation; raise an open point and a clarification question. Acceptance condition Customer answers the linked open point. Responsibility assumption OEM / Customer Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: None |
| REQ_SEC_0003 | Cybersecurity concept REQ_SEC_0003 The supplier shall describe the cybersecurity concept and...Cybersecurity concept REQ_SEC_0003 The supplier shall describe the cybersecurity concept and how it is implemented in hardware and software respectively. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 5 | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm or correct the stated supplier assumption. | - | Cybersecurity requirement handling | OEM/Customer Review Interface | High | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 5 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Cybersecurity requirement handling | Interface: OEM/Customer Review Interface | SSR: SSR-CON-001 |
| REQ_SEC_0022 | Marcus Lindner EPXC Published 6(16) REQ_SEC_0022 All risks identified in cybersecurity risk a...Marcus Lindner EPXC Published 6(16) REQ_SEC_0022 All risks identified in cybersecurity risk analyses shall be evaluated. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | Cybersecurity requirement handling | None | High | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Cybersecurity requirement handling | Interface: None | SSR: SSR-CON-001 |
| REQ-AUTO-00009 | For each risk identified in the cybersecurity risk analyses, a risk treatment decision shall...For each risk identified in the cybersecurity risk analyses, a risk treatment decision shall be made to avoid, reduce, share, or retain the risk. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm or correct the stated supplier assumption. | - | Cybersecurity requirement handling | None | High | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Cybersecurity requirement handling | Interface: None | SSR: SSR-CON-001 |
| REQ_SEC_0023 | REQ_SEC_0023 Cybersecurity controls shall sufficiently reduce the risk.REQ_SEC_0023 Cybersecurity controls shall sufficiently reduce the risk. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | Cybersecurity requirement handling | None | High | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Cybersecurity requirement handling | Interface: None | SSR: SSR-CON-001 |
| REQ-AUTO-00011 | It shall be possible to verify which cybersecurity controls were derived from which requireme...It shall be possible to verify which cybersecurity controls were derived from which requirements. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | Cybersecurity requirement handling | None | High | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Cybersecurity requirement handling | Interface: None | SSR: SSR-CON-001 |
| REQ_SEC_0024 | REQ_SEC_0024 The cybersecurity concept of the supplier shall contain a documentation of the a...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. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm or correct the stated supplier assumption. | - | Cybersecurity requirement handling | OEM/Customer Review Interface | High | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Cybersecurity requirement handling | Interface: OEM/Customer Review Interface | SSR: SSR-CON-001 |
| REQ_SEC_0004 | Verification and validation REQ_SEC_0004 The supplier shall provide documentation of the veri...Verification and validation REQ_SEC_0004 The supplier shall provide documentation of the verification and validation methods of cybersecurity features. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | Cybersecurity requirement handling | OEM/Customer Review Interface | High | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Cybersecurity requirement handling | Interface: OEM/Customer Review Interface | SSR: SSR-CON-001 |
| REQ_SEC_0005 | REQ_SEC_0005 The supplier shall provide test reports detailing the results from the verificat...REQ_SEC_0005 The supplier shall provide test reports detailing the results from the verification and validation of cybersecurity features. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | Cybersecurity requirement handling | OEM/Customer Review Interface | High | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Cybersecurity requirement handling | Interface: OEM/Customer Review Interface | SSR: SSR-CON-001 |
| REQ_SEC_0040 | REQ_SEC_0040 The vehicle manufacturer reserves the right to perform penetration testing on th...REQ_SEC_0040 The vehicle manufacturer reserves the right to perform penetration testing on the ECU to identify potential vulnerabilities. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_SEC_0007 | Documentation REQ_SEC_0007 An inventory of software and protocols, including their versions,...Documentation REQ_SEC_0007 An inventory of software and protocols, including their versions, shall be provided by the supplier. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-007 |
| REQ_SEC_0025 | Marcus Lindner EPXC Published 7(16) REQ_SEC_0025 A BOM containing part numbers and versions o...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. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 7 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | High | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 7 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-COM-001 |
| REQ_SEC_0041 | REQ_SEC_0041 The vehicle manufacturer reserves the right to request documentation and evidenc...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. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 7 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 7 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_SEC_0042 | REQ_SEC_0042 The vehicle manufacturer and the supplier shall set up a cybersecurity DIA to ag...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. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 7 | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm or correct the stated supplier assumption. | - | Cybersecurity requirement handling | OEM/Customer Review Interface | High | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 7 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Cybersecurity requirement handling | Interface: OEM/Customer Review Interface | SSR: SSR-CON-001 |
| REQ_SEC_0008 | Software security REQ_SEC_0008 The ECU shall be able to verify integrity and authenticity of...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. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 7 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | Authentication | OEM/Customer Review Interface | High | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 7 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Authentication | Interface: OEM/Customer Review Interface | SSR: SSR-DAI-001 |
| REQ-AUTO-00021 | Methods shall be proposed to and approved by the vehicle manufacturer.Methods shall be proposed to and approved by the vehicle manufacturer. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 7 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 7 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-001 |
| REQ_SEC_0009 | Security architecture REQ_SEC_0009 The supplier shall apply methods for isolation of software...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. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 7 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | Cybersecurity requirement handling | OEM/Customer Review Interface | High | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 7 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Cybersecurity requirement handling | Interface: OEM/Customer Review Interface | SSR: SSR-CON-001 |
| REQ_SEC_0020 | Cryptographic libraries REQ_SEC_0020 Selection of cryptographic methods and their use shall b...Cryptographic libraries REQ_SEC_0020 Selection of cryptographic methods and their use shall be agreed upon between the vehicle manufacturer and the supplier. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 7 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | High | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 7 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-001 |
| REQ_SEC_0010 | Services REQ_SEC_0010 All network services implemented in the ECU shall undergo hardening.Services REQ_SEC_0010 All network services implemented in the ECU shall undergo hardening. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-PROD-001 |
| REQ_SEC_0011 | REQ_SEC_0011 The ECU shall only expose network and communication services that have been agre...REQ_SEC_0011 The ECU shall only expose network and communication services that have been agreed upon with the vehicle manufacturer. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Low | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-COM-001 |
| REQ_SEC_0012 | Interfaces REQ_SEC_0012 Communication interfaces shall use boundary controls such as ingress/...Interfaces REQ_SEC_0012 Communication interfaces shall use boundary controls such as ingress/egress filtering. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-001 |
| REQ_SEC_0013 | REQ_SEC_0013 Communication boundary controls shall be configurable by the vehicle manufacturer.REQ_SEC_0013 Communication boundary controls shall be configurable by the vehicle manufacturer. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-001 |
| REQ-AUTO-00028 | Methods shall be proposed and approved by the vehicle manufacturer.Methods shall be proposed and approved by the vehicle manufacturer. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-001 |
| REQ_SEC_0014 | REQ_SEC_0014 Any interfaces used for development purposes shall be removed or disabled in ser...REQ_SEC_0014 Any interfaces used for development purposes shall be removed or disabled in series production. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-001 |
| REQ-AUTO-00030 | The details shall be agreed upon between the vehicle manufacturer and the supplier.The details shall be agreed upon between the vehicle manufacturer and the supplier. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-001 |
| REQ_SEC_0026 | REQ_SEC_0026 Only hardware interfaces and protocols specified by the vehicle manufacturer sha...REQ_SEC_0026 Only hardware interfaces and protocols specified by the vehicle manufacturer shall be available in series production. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm production/debug hardening expectations (debug lock, secure end-of-line, developer-access policy). | OP-008 | None | OEM/Customer Review Interface | Low | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-COM-001 |
| REQ_SEC_0027 | Information security REQ_SEC_0027 It shall be possible for the vehicle manufacturer to secure...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. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | Cybersecurity requirement handling | OEM/Customer Review Interface | High | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Cybersecurity requirement handling | Interface: OEM/Customer Review Interface | SSR: SSR-CON-001 |
| REQ_SEC_0028 | Marcus Lindner EPXC Published 9(16) REQ_SEC_0028 Data specified by the vehicle manufacturer s...Marcus Lindner EPXC Published 9(16) REQ_SEC_0028 Data specified by the vehicle manufacturer shall be protected from manipulations. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 9 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 9 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-001 |
| REQ_SEC_0029 | REQ_SEC_0029 Data specified by the vehicle manufacturer shall be protected from disclosure.REQ_SEC_0029 Data specified by the vehicle manufacturer shall be protected from disclosure. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 9 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 9 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-001 |
| REQ_SEC_0006 | REQ_SEC_0006 Intellectual property of the vehicle manufacturer shall be protected from disclo...REQ_SEC_0006 Intellectual property of the vehicle manufacturer shall be protected from disclosure. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 9 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 9 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-001 |
| REQ_SEC_0016 | Key management REQ_SEC_0016 It shall be possible for the vehicle manufacturer to securely inj...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. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 9 | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier. | OP-003 | Key management | OEM/Customer Review Interface | High | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 9 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Key management | Interface: OEM/Customer Review Interface | SSR: SSR-KEY-001 |
| REQ_SEC_0019 | REQ_SEC_0019 Secrets, public keys and other data used for cybersecurity controls in productio...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. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 9 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | Key management | None | High | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 9 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Key management | Interface: None | SSR: SSR-KEY-001 |
| REQ_SEC_0021 | REQ_SEC_0021 ECUs shall only contain the secrets agreed between the vehicle manufacturer and...REQ_SEC_0021 ECUs shall only contain the secrets agreed between the vehicle manufacturer and the supplier. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 9 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Low | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 9 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-001 |
| REQ_SEC_0015 | REQ_SEC_0015 ECUs shall conform to the harmonized Security Access specification [1] provided...REQ_SEC_0015 ECUs shall conform to the harmonized Security Access specification [1] provided by the vehicle manufacturer. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 9 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | Cybersecurity requirement handling | OEM/Customer Review Interface | High | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 9 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Cybersecurity requirement handling | Interface: OEM/Customer Review Interface | SSR: SSR-CON-001 |
| REQ_SEC_0043 | Security updates REQ_SEC_0043 It shall be possible to update the software of the ECU.Security updates REQ_SEC_0043 It shall be possible to update the software of the ECU. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 9 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | Cybersecurity requirement handling | None | High | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 9 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Cybersecurity requirement handling | Interface: None | SSR: SSR-CON-001 |
| REQ_SEC_0030 | Marcus Lindner EPXC Published 10(16) REQ_SEC_0030 The supplier shall inform the vehicle manuf...Marcus Lindner EPXC Published 10(16) REQ_SEC_0030 The supplier shall inform the vehicle manufacturer if any cybersecurity patches are available. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 | Accept with Assumption | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Confirm or correct the stated supplier assumption. | - | Cybersecurity requirement handling | OEM/Customer Review Interface | High | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Cybersecurity requirement handling | Interface: OEM/Customer Review Interface | SSR: SSR-CON-001 |
| REQ_SEC_0044 | Incident management REQ_SEC_0044 An incident response process shall be proposed to and approv...Incident management REQ_SEC_0044 An incident response process shall be proposed to and approved by the vehicle manufacturer. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 | Accept with Assumption | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-VIH-002 |
| REQ_SEC_0045 | REQ_SEC_0045 In case of cybersecurity incidents, the incident response process shall be used.REQ_SEC_0045 In case of cybersecurity incidents, the incident response process shall be used. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 | Accept with Assumption | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Confirm or correct the stated supplier assumption. | - | Incident response | None | High | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Incident response | Interface: None | SSR: SSR-VIH-003 |
| REQ_SEC_0046 | REQ_SEC_0046 The incident response process shall be maintained for the entire product lifetime.REQ_SEC_0046 The incident response process shall be maintained for the entire product lifetime. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 | Accept with Assumption | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-VIH-002 |
| REQ_SEC_0032 | REQ_SEC_0032 The incident response process shall ensure that risk is managed in coordination...REQ_SEC_0032 The incident response process shall ensure that risk is managed in coordination with the vehicle manufacturer. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 | Accept with Assumption | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-VIH-002 |
| REQ_SEC_0033 | Vulnerability management REQ_SEC_0033 Any vulnerabilities that are identified during product...Vulnerability management REQ_SEC_0033 Any vulnerabilities that are identified during product lifecycle shall be promptly communicated to the vehicle manufacturer. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 | Accept with Assumption | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-VIH-004 |
| REQ-AUTO-00047 | The report shall include information needed to identify the affected vehicles/products.The report shall include information needed to identify the affected vehicles/products. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-001 |
| REQ-AUTO-00048 | Methods including the stipulation of a reasonable notification time shall be proposed to and...Methods including the stipulation of a reasonable notification time shall be proposed to and approved by the vehicle manufacturer. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-001 |
| REQ_SEC_0034 | REQ_SEC_0034 Following each identified and reported vulnerability, the supplier and vehicle m...REQ_SEC_0034 Following each identified and reported vulnerability, the supplier and vehicle manufacturer shall agree on an initial response to the vulnerability. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 | Partially Accept | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Confirm the split of monitoring, triage, vulnerability handling and field response between OEM PSIRT and supplier. | OP-006 | None | OEM/Customer Review Interface | Medium | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-VIH-004 |
| REQ_SEC_0035 | Marcus Lindner EPXC Published 11(16) REQ_SEC_0035 Within adequate time after the initial vuln...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. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 11 | Accept with Assumption | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 11 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-VIH-004 |
| REQ-AUTO-00051 | The information shall contain • the version(s) of affected hardware or software components, •...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. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 11 | Accept with Assumption | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Confirm or correct the stated supplier assumption. | - | Vulnerability management | None | High | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 11 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Vulnerability management | Interface: None | SSR: SSR-VIH-001 |
| REQ-AUTO-00052 | Methods including the stipulation of a reasonable reporting time shall be proposed to and app...Methods including the stipulation of a reasonable reporting time shall be proposed to and approved by the vehicle manufacturer. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 11 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 11 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-001 |
| REQ_SEC_0036 | REQ_SEC_0036 The supplier shall have a method for monitoring available vulnerability database...REQ_SEC_0036 The supplier shall have a method for monitoring available vulnerability databases for vulnerabilities that can affect the delivered product. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 11 | Accept with Assumption | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces; OEM/Customer Review Interface | Medium | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 11 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces; OEM/Customer Review Interface | SSR: SSR-VIH-005 |
| REQ_SEC_0037 | REQ_SEC_0037 Identified vulnerabilities shall be considered in all current development projec...REQ_SEC_0037 Identified vulnerabilities shall be considered in all current development projects or projects under field monitoring. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 11 | Accept with Assumption | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 11 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-001 |
| REQ_SEC_0047 | Product lifecycle REQ_SEC_0047 An ECU returned from field shall allow for field-return analysis.Product lifecycle REQ_SEC_0047 An ECU returned from field shall allow for field-return analysis. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 11 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 11 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-HW-001 |
| REQ_SEC_0048 | REQ_SEC_0048 Field-return analysis secrets shall not be operational in the field.REQ_SEC_0048 Field-return analysis secrets shall not be operational in the field. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 11 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Low | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 11 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-001 |
| REQ_SEC_0049 | REQ_SEC_0049 An ECU enabled for field-return analysis shall not be possible to use as a spare...REQ_SEC_0049 An ECU enabled for field-return analysis shall not be possible to use as a spare part. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 11 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 11 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-LIFE-001 |
| REQ_SEC_0050 | Marcus Lindner EPXC Published 12(16) REQ_SEC_0050 All secrets specified by the vehicle manufa...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. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 12 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 12 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-COM-001 |
| REQ-AUTO-00059 | End-of-life and decommissioning shall be specifically considered.End-of-life and decommissioning shall be specifically considered. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 12 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 12 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-LIFE-002 |
| REQ-AUTO-00060 | Notes: a) It shall not be possible for a third party to reuse an ECU without system support f...Notes: a) It shall not be possible for a third party to reuse an ECU without system support from the vehicle manufacturer. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 12 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | OEM/Customer Review Interface | Low | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 12 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-HW-001 |
| REQ-AUTO-00061 | b) Decommissioning of an ECU shall not have the potential of causing unacceptable risk to the...b) Decommissioning of an ECU shall not have the potential of causing unacceptable risk to the road user or the vehicle manufacturer. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 12 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | OEM/Customer Review Interface | Low | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 12 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-LIFE-001 |
| REQ_SEC_0051 | Logging REQ_SEC_0051 Security related events shall be identified and logged.Logging REQ_SEC_0051 Security related events shall be identified and logged. | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf | 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 12 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | Logging and audit trail | None | High | Pending | DetailsDocument section 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 12 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Logging and audit trail | Interface: None | SSR: SSR-LOG-001 |
| REQ-AUTO-00063 | The gearbox itself shall be used in all drivetrains and the ECA shall be common and must be c...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 3 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 3 Document section 3299216_1 > Page 3 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-001 |
| REQ-AUTO-00064 | P 1 Page 2 General 2.1 The clutch actuator shall be electrically driven.P 1 Page 2 General 2.1 The clutch actuator shall be electrically driven. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 4 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 4 Document section 3299216_1 > Page 4 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-001 |
| REQ-AUTO-00065 | 2.2 The actuator is placed outside of the gearbox 2.3 The ECA (Electric Clutch Actuator) must...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 4 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 4 Document section 3299216_1 > Page 4 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-HW-001 |
| REQ-AUTO-00066 | 2.4 The actuator will be controlled by a position and speed demand by CAN-bus 2.5 The actuato...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). | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 4 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 4 Document section 3299216_1 > Page 4 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-00067 | The variant type shall be based on delivery agreement and Brand involved.The variant type shall be based on delivery agreement and Brand involved. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 4 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 4 Document section 3299216_1 > Page 4 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-001 |
| REQ-AUTO-00068 | Common marking requirements that must be fulfilled for each marking variant are: Marking meth...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 4 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 4 Document section 3299216_1 > Page 4 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-001 |
| REQ-AUTO-00069 | The marking shall not be visible when the ECA is mounted on a gearbox.The marking shall not be visible when the ECA is mounted on a gearbox. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 4 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 4 Document section 3299216_1 > Page 4 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-001 |
| REQ-AUTO-00070 | The ECA units shall be delivered to the required Traton brand’s production in a position in t...The ECA units shall be delivered to the required Traton brand’s production in a position in the pallet where the marking is visible. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 4 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 4 Document section 3299216_1 > Page 4 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-001 |
| REQ-AUTO-00071 | 4.16) shall be marked according to the requirements in Scania STD19 (Ref 14.17) Tentik, wordm...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 5 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 5 Document section 3299216_1 > Page 5 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-001 |
| REQ-AUTO-00072 | Alternative design: CXM or equivalent combination of date dial and date field The rubber cove...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 5 | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm or correct the stated supplier assumption. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 5 Document section 3299216_1 > Page 5 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-001 |
| REQ-AUTO-00073 | Details to be agreed with Traton 2.9 Traton shall be invited to participate in electrical and...Details to be agreed with Traton 2.9 Traton shall be invited to participate in electrical and mechanical design reviews. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 5 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 5 Document section 3299216_1 > Page 5 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-001 |
| REQ-AUTO-00074 | 2.10 Traton requires extensive testing to be performed by the supplier to verify all demands...2.10 Traton requires extensive testing to be performed by the supplier to verify all demands stated in the requirement specification. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 5 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 5 Document section 3299216_1 > Page 5 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-001 |
| REQ-AUTO-00075 | 2.11 The mechanics shall also be tested and verified, in an overall durability test as stated...2.11 The mechanics shall also be tested and verified, in an overall durability test as stated in Appendix B etc. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 5 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 5 Document section 3299216_1 > Page 5 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-001 |
| REQ-AUTO-00076 | 2.12 Traton requires: - Documentation of the product, i.e.2.12 Traton requires: - Documentation of the product, i.e. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 5 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 5 Document section 3299216_1 > Page 5 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-001 |
| REQ-AUTO-00077 | Should the PP be fully calculated from the AP-sensor, then this offset should not exist.Should the PP be fully calculated from the AP-sensor, then this offset should not exist. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 7 | Needs Internal Review | Needs internal review. Confirm whether this should-level requirement is in the committed baseline. | No customer action until supplier review is complete. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 7 Document section 3299216_1 > Page 7 Supplier rationale Non-mandatory wording; baseline inclusion not yet confirmed. Implementation approach Decide baseline inclusion internally, then issue an Accept/Partial position. Acceptance condition Internal baseline decision recorded. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00078 | P 1 Page 4 Mechanical interface 4.1 The maximum release stroke is 22,4 mm from FCCP 4.2 The t...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 8 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. | OP-004 | None | External Interfaces | High | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 8 Document section 3299216_1 > Page 8 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-00079 | 4.3 The clutch actuator shall be able to reach the extreme positions A and B in with the cent...4.3 The clutch actuator shall be able to reach the extreme positions A and B in with the center of the pushrod end. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 8 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 8 Document section 3299216_1 > Page 8 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-001 |
| REQ-AUTO-00080 | P 1 Page 4.4 ECA shall not interfere with any geometry in the 3D envelope 53612101-1 1_RFQ203...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 9 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 9 Document section 3299216_1 > Page 9 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-001 |
| REQ-AUTO-00081 | 4.6 When the ECA is assembled, it shall not be possible to insert an object larger than Ø0,2...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 9 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 9 Document section 3299216_1 > Page 9 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00082 | 4.7 When the ECA is assembled, a gap of 3,5 mm towards surface B with a profile tolerance of...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 9 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 9 Document section 3299216_1 > Page 9 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-001 |
| REQ-AUTO-00083 | The surface roughness of the ECA opposite to surface B shall be equal or finer than Ra 3,2 µm.The surface roughness of the ECA opposite to surface B shall be equal or finer than Ra 3,2 µm. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 9 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 9 Document section 3299216_1 > Page 9 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-001 |
| REQ-AUTO-00084 | 4.8 The ECA shall be adapted for 6 pcs M8 flange screws described by Scania STD44354.8 The ECA shall be adapted for 6 pcs M8 flange screws described by Scania STD4435 | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 9 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 9 Document section 3299216_1 > Page 9 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-001 |
| REQ-AUTO-00085 | P 1 Page 4.9 The ECA shall be adapted for 2 pcs 10 mm guide pins.P 1 Page 4.9 The ECA shall be adapted for 2 pcs 10 mm guide pins. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 10 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 10 Document section 3299216_1 > Page 10 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-001 |
| REQ-AUTO-00086 | Figure 5 - Gearbox flange 4.10 The guide pin holes in the ECA shall be Ø 10,1±0.05 mm and at...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 10 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 10 Document section 3299216_1 > Page 10 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-001 |
| REQ-AUTO-00087 | The holes shall also block the guide pin from protruding more than 14 mm from the gearbox hou...The holes shall also block the guide pin from protruding more than 14 mm from the gearbox housing. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 10 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 10 Document section 3299216_1 > Page 10 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-001 |
| REQ-AUTO-00088 | 4.11 The ECA shall be able to be held by the guide pins only while being exposed to the max c...4.11 The ECA shall be able to be held by the guide pins only while being exposed to the max clutch load, (req. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 10 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 10 Document section 3299216_1 > Page 10 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-001 |
| REQ-AUTO-00089 | Surface indents in the contacts are allowed as long as the structural integrity is unaffected...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 10 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 10 Document section 3299216_1 > Page 10 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DAI-002 |
| REQ-AUTO-00090 | 4.13 It shall be possible to pull the pushrod 50 times with a force of 300 N without risk for...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 10 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 10 Document section 3299216_1 > Page 10 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00091 | Alternatively it can have a loose fit in the ECA, but it shall be possible to reconnect it by...Alternatively it can have a loose fit in the ECA, but it shall be possible to reconnect it by pushing it back by hand. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 10 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 10 Document section 3299216_1 > Page 10 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-003 |
| REQ-AUTO-00092 | 4.14 The ECA shall allow space for external tools according to the cylinders in the 3D envelo...4.14 The ECA shall allow space for external tools according to the cylinders in the 3D envelope attached. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 10 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 10 Document section 3299216_1 > Page 10 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-001 |
| REQ-AUTO-00093 | 4.15 The ECA shall have a window where the volume shown in Figure 6 – Snap in tool space, cou...4.15 The ECA shall have a window where the volume shown in Figure 6 – Snap in tool space, could pass through(See req. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 10 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 10 Document section 3299216_1 > Page 10 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-004 |
| REQ-AUTO-00094 | 4.16 The ECA shall provide a support for a clutch snap in tool on the marked surface in Figur...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 10 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 10 Document section 3299216_1 > Page 10 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-004 |
| REQ-AUTO-00095 | P 1 Page 4.17 The hole shall be equipped with a cover possible to assemble and disassemble at...P 1 Page 4.17 The hole shall be equipped with a cover possible to assemble and disassemble at least 50 times without tools. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 11 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 11 Document section 3299216_1 > Page 11 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00096 | If an interference fit is chosen, the maximum force to assemble/disassemble shall be 50 N in...If an interference fit is chosen, the maximum force to assemble/disassemble shall be 50 N in room temperature. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 11 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 11 Document section 3299216_1 > Page 11 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| req.10.5 | It shall still remain intac t and keep tightness after vibration testing (See req.10.5) 4.18...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 11 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 11 Document section 3299216_1 > Page 11 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00098 | Figure 6 - Snap in tool space 4.19 The ECA shall have a loop or similar feature where the cab...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 11 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 11 Document section 3299216_1 > Page 11 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-COM-004 |
| REQ-AUTO-00099 | The loop or Scania assembled bracket shall be located close to the centre ( ± 20 mm) of the c...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 11 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 11 Document section 3299216_1 > Page 11 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-COM-005 |
| REQ-AUTO-00100 | Details regarding actual length and positioning tolerances shall be agreed in design phase.Details regarding actual length and positioning tolerances shall be agreed in design phase. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 11 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 11 Document section 3299216_1 > Page 11 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00101 | 4.21 If the ECA is powered up with the PP in the utmost forward position (for example when no...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 11 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 11 Document section 3299216_1 > Page 11 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00102 | 4.23 The actuator shall apply a preload force for the release bearing.4.23 The actuator shall apply a preload force for the release bearing. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 12 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 12 Document section 3299216_1 > Page 12 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00103 | The preload force measured on the push rod shall be 150N to 250N independent of the clutch po...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). | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 12 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 12 Document section 3299216_1 > Page 12 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00104 | 4.25 It must be possible to assemble the actuator independent of the lever position without a...4.25 It must be possible to assemble the actuator independent of the lever position without any power connection. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 12 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 12 Document section 3299216_1 > Page 12 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00105 | This means that the push rod shall be possible to move by hand.This means that the push rod shall be possible to move by hand. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 12 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 12 Document section 3299216_1 > Page 12 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00106 | 4.26 When the clutch is fully engaged, the active control mode is position or torque control...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 12 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 12 Document section 3299216_1 > Page 12 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| req-5.10 | P 1 Page 5 Clutch engage and disengage 5.1 It shall be possible to disengage the clutch in 18...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 13 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 13 Document section 3299216_1 > Page 13 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-003 |
| REQ-AUTO-00108 | This shall be measured against the maximum disengage force (See Appendix A) Figure 7 – Maximu...This shall be measured against the maximum disengage force (See Appendix A) Figure 7 – Maximum disengage time | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 13 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 13 Document section 3299216_1 > Page 13 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| req-6.4 | P 1 Page 5.2 It shall be possible to engage the clutch in 180ms (=Ts) with accuracy according...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). | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 14 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 14 Document section 3299216_1 > Page 14 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00110 | This shall be measured against the minimum engage force (See Appendix A) Figure 8 - Maximum e...This shall be measured against the minimum engage force (See Appendix A) Figure 8 - Maximum engage time | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 14 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 14 Document section 3299216_1 > Page 14 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00111 | P 1 Page 5.3 The clutch actuator shall report the absolute position of the current actuator s...P 1 Page 5.3 The clutch actuator shall report the absolute position of the current actuator stroke (AP) (Ref 14.14). | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 15 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 15 Document section 3299216_1 > Page 15 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00112 | 5.4 It shall also report the position that corresponds to a fully closed clutch position (FCC...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 15 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 15 Document section 3299216_1 > Page 15 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00113 | 5.5 The clutch actuator shall be equipped with a displacement sensor measuring the movement o...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 15 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 15 Document section 3299216_1 > Page 15 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-HW-001 |
| REQ-AUTO-00114 | Range: 85mm (AP) 5.7 For each stroke that the actuator performs it shall adjust to the curren...Range: 85mm (AP) 5.7 For each stroke that the actuator performs it shall adjust to the current wear of the clutch. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 15 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 15 Document section 3299216_1 > Page 15 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00115 | This means that is shall be possible to request a relative stroke from the fully closed clutc...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 15 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 15 Document section 3299216_1 > Page 15 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00116 | The FCCP after a clutch engage shall be updated to 90% of the step within 0,2 s per mm that t...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 15 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 15 Document section 3299216_1 > Page 15 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00117 | 5.9 The maximum stationary position error relative to real FCCP (i e self-adjustment error +...5.9 The maximum stationary position error relative to real FCCP (i e self-adjustment error + step response error) shall be ±0.15mm. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 15 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 15 Document section 3299216_1 > Page 15 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00118 | P 1 Page 5.10 The actuator shall move the pushrod according to the following points: Actuator...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 16 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 16 Document section 3299216_1 > Page 16 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00119 | The actuator shall move the pushrod at the highest possible speed, limited only by its maximu...The actuator shall move the pushrod at the highest possible speed, limited only by its maximum achievable speed and the maximum speed request. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 16 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 16 Document section 3299216_1 > Page 16 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00120 | 6.4) Dynamics start of movement: The requested speed (or 125mm/s, if requested speed > 125mm/...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 16 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 16 Document section 3299216_1 > Page 16 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00121 | Dynamics end of movement: The requested speed shall be kept until 2 mm from the target position.Dynamics end of movement: The requested speed shall be kept until 2 mm from the target position. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 16 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 16 Document section 3299216_1 > Page 16 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00122 | 100ms after reaching 2 mm from target, the maximum position error should be ±0.1mm.100ms after reaching 2 mm from target, the maximum position error should be ±0.1mm. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 16 | Needs Internal Review | Needs internal review. Confirm whether this should-level requirement is in the committed baseline. | No customer action until supplier review is complete. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 16 Document section 3299216_1 > Page 16 Supplier rationale Non-mandatory wording; baseline inclusion not yet confirmed. Implementation approach Decide baseline inclusion internally, then issue an Accept/Partial position. Acceptance condition Internal baseline decision recorded. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: None |
| req-5.1 | The full strokes should be performed within 180 ms, as specified in req 5.1 and 5.2.The full strokes should be performed within 180 ms, as specified in req 5.1 and 5.2. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 16 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 16 Document section 3299216_1 > Page 16 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-009 |
| REQ-AUTO-00124 | 5.10 shall be tested with a step response test cycle, according to description and Figure 10...5.10 shall be tested with a step response test cycle, according to description and Figure 10 - Step response test cycle. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 17 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 17 Document section 3299216_1 > Page 17 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00125 | P 1 Page 5.12 The ECA shall be able to run the 4 second test cycle in Figure 11 - Release fre...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 18 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 18 Document section 3299216_1 > Page 18 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| req-8.1 | The test shall be done with the highest operating temperature (see req 8.1) and maximum clutc...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 | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 18 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 18 Document section 3299216_1 > Page 18 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00127 | Between 16V and loss of power the ECA shall hold its current position or move towards request...Between 16V and loss of power the ECA shall hold its current position or move towards requested position without any time requirement. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 19 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 19 Document section 3299216_1 > Page 19 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00128 | The strategy shall be disc ussed and approved with Traton.The strategy shall be disc ussed and approved with Traton. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 19 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 19 Document section 3299216_1 > Page 19 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00129 | 5.1 and 5.2) Figure 12 - Class B exceptions 5.14 It shall be possible to keep the clutch dise...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 19 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 19 Document section 3299216_1 > Page 19 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00130 | This shall be measured against the maximum disengage force (Appendix A) and an highest operat...This shall be measured against the maximum disengage force (Appendix A) and an highest operating temperature (see req. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 19 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 19 Document section 3299216_1 > Page 19 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00131 | P 1 Page 6 SW functionality 6.1 TB4684 shall be applied.P 1 Page 6 SW functionality 6.1 TB4684 shall be applied. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 20 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 20 Document section 3299216_1 > Page 20 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00132 | It shall be followed to its full extent.It shall be followed to its full extent. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 20 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 20 Document section 3299216_1 > Page 20 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00133 | When requesting Absolute Position Control the actuator shall move to the actuator position de...When requesting Absolute Position Control the actuator shall move to the actuator position defined by the Requested Position (RP). | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 21 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 21 Document section 3299216_1 > Page 21 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00134 | Specific cases shall be approved with Traton.Specific cases shall be approved with Traton. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 21 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 21 Document section 3299216_1 > Page 21 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00135 | Control mode Absolute position 0x01 6.3.2 When requesting Relative Position Control (RPC) the...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). | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 21 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 21 Document section 3299216_1 > Page 21 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00136 | Control mode Relative position 0x02 6.3.3 When requesting Torque Control (TC) the actuator sh...Control mode Relative position 0x02 6.3.3 When requesting Torque Control (TC) the actuator shall actuate the requested motor torque. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 21 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 21 Document section 3299216_1 > Page 21 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00137 | 6.3.4 When requesting Test Mode, the actuator shall perform tests to detect latent faults.6.3.4 When requesting Test Mode, the actuator shall perform tests to detect latent faults. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 22 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 22 Document section 3299216_1 > Page 22 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00138 | ECA behavior and additional requirements for this mode can be found in (Ref 14.16) Control mo...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 22 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 22 Document section 3299216_1 > Page 22 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-00139 | CAN communication shall still be active.CAN communication shall still be active. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 22 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 22 Document section 3299216_1 > Page 22 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-00140 | If the actuator can move faster than this value it shall be controlled in a such way that it...If the actuator can move faster than this value it shall be controlled in a such way that it does not exceed this limit. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 22 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 22 Document section 3299216_1 > Page 22 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-003 |
| REQ-AUTO-00141 | 6.5 Self-adjustment The self-adjustment signal defines the restrictions of how the FCCP shall...6.5 Self-adjustment The self-adjustment signal defines the restrictions of how the FCCP shall be identified. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 22 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 22 Document section 3299216_1 > Page 22 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| req-6.3 | The signal is valid during Control Modes RPC and TC(see req 6.3).The signal is valid during Control Modes RPC and TC(see req 6.3). | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 22 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 22 Document section 3299216_1 > Page 22 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00143 | The value of the FCCP shall be reported via CAN(Ref 14.14) Req.The value of the FCCP shall be reported via CAN(Ref 14.14) Req. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 22 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 22 Document section 3299216_1 > Page 22 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-00144 | The value shall be frozen at the last identified position and used for RPC.The value shall be frozen at the last identified position and used for RPC. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 22 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 22 Document section 3299216_1 > Page 22 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00145 | 6.6.1 When low accuracy mode is requested, the maximum push rod position(PP) error can be ±0....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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 23 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 23 Document section 3299216_1 > Page 23 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-00146 | Message contents to be agreed with Traton 6.9 ECA identification number: The ECA shall report...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 23 | Needs Customer Clarification | Needs customer clarification. The requirement implies customer-owned infrastructure, approval, or a responsibility split that is not yet available. | Scope and responsibility for each listed requirement. | OP-011 | None | External Interfaces; OEM/Customer Review Interface | Unknown | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 23 Document section 3299216_1 > Page 23 Supplier rationale Flagged customer_clarification_needed=yes during extraction. Implementation approach Hold implementation; raise an open point and a clarification question. Acceptance condition Customer answers the linked open point. Responsibility assumption OEM / Customer Traceability Capability: None | Interface: External Interfaces; OEM/Customer Review Interface | SSR: None |
| REQ-AUTO-00147 | 6.11 SW number: The ECA shall report a complete SW version number.6.11 SW number: The ECA shall report a complete SW version number. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 23 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 23 Document section 3299216_1 > Page 23 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00148 | 6.12 HW number: The ECA shall report a complete HW version number.6.12 HW number: The ECA shall report a complete HW version number. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 23 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 23 Document section 3299216_1 > Page 23 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| req-6.20 | 6.13 Error State Diagnostic - ESD and Error State Action - ESA The ECA shall send a bit field...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 23 | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm or correct the stated supplier assumption. | - | Diagnostic security | None | High | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 23 Document section 3299216_1 > Page 23 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Diagnostic security | Interface: None | SSR: SSR-RBAC-001 |
| REQ-AUTO-00150 | ESA definition( Ref 14.16) The supplier shall provide documentation for the ESD bits and rela...ESA definition( Ref 14.16) The supplier shall provide documentation for the ESD bits and related faults . | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 23 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 23 Document section 3299216_1 > Page 23 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-002 |
| REQ-AUTO-00151 | 6.14 System state The ECA shall report its current System State.6.14 System state The ECA shall report its current System State. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 23 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 23 Document section 3299216_1 > Page 23 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00152 | 6.14.1 Boot Mode If the actuator is in boot mode, 0x00 shall be reported as active state.6.14.1 Boot Mode If the actuator is in boot mode, 0x00 shall be reported as active state. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 24 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 24 Document section 3299216_1 > Page 24 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00153 | 0x0 6.14.2 Absolute Position Control This value shall be sent when the ECA is actuating Absol...0x0 6.14.2 Absolute Position Control This value shall be sent when the ECA is actuating Absolute Position Control. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 24 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 24 Document section 3299216_1 > Page 24 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00154 | 0x1 6.14.3 Relative Position Control This value shall be sent when the ECA is actuating Relat...0x1 6.14.3 Relative Position Control This value shall be sent when the ECA is actuating Relative Position Control. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 24 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 24 Document section 3299216_1 > Page 24 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00155 | 0x2 6.14.4 Torque Control This value shall be sent when the ECA is actuating Torque Control.0x2 6.14.4 Torque Control This value shall be sent when the ECA is actuating Torque Control. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 24 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 24 Document section 3299216_1 > Page 24 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00156 | 0x4 6.14.5 Self-Adjustment This value shall be sent when the ECA is performing a Self-Adjustm...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 24 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 24 Document section 3299216_1 > Page 24 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00157 | 0x5 6.14.6 Initializing This value shall be sent when the ECA is performing its initiation ro...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 24 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 24 Document section 3299216_1 > Page 24 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-002 |
| REQ-AUTO-00158 | 0xA 6.14.7 Shut down This value shall be sent when the ECA is performing its shut down routin...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 24 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 24 Document section 3299216_1 > Page 24 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00159 | 0xB 6.14.8 Debug / Test This value shall be sent when the actuator is in debug or test contro...0xB 6.14.8 Debug / Test This value shall be sent when the actuator is in debug or test control state. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 24 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 24 Document section 3299216_1 > Page 24 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00160 | 0xC 6.14.9 Motor Brake Simulation This value shall be sent when the actuator is performing a...0xC 6.14.9 Motor Brake Simulation This value shall be sent when the actuator is performing a motor brake simulation. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 24 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 24 Document section 3299216_1 > Page 24 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00161 | P 1 Page 6.15 System Temperature The ECA shall report the current system temperature.(Ref 14....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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 25 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 25 Document section 3299216_1 > Page 25 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00162 | (Ref 14.14) 6.17 Current feedback The ECA shall report the current for each phase of the actu...(Ref 14.14) 6.17 Current feedback The ECA shall report the current for each phase of the actuator. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 25 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 25 Document section 3299216_1 > Page 25 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00163 | These values shall be calculated using a moving mean filter.These values shall be calculated using a moving mean filter. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 25 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 25 Document section 3299216_1 > Page 25 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00164 | The filter time shall equal the update frequency .The filter time shall equal the update frequency . | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 25 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 25 Document section 3299216_1 > Page 25 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00165 | (Ref 14.14) 6.18 Supply Voltage Feedback The ECA shall report the current system voltage.(Ref 14.14) 6.18 Supply Voltage Feedback The ECA shall report the current system voltage. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 25 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 25 Document section 3299216_1 > Page 25 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| Req.ID-Description-6.19.1 | (input voltage) (Ref 14.14) 6.19 Operational data The following operational data deemed impor...(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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 25 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 25 Document section 3299216_1 > Page 25 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00167 | 6.19.2 Total travelled length: The ECA shall report its accumulated lifetime travel length.6.19.2 Total travelled length: The ECA shall report its accumulated lifetime travel length. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 25 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 25 Document section 3299216_1 > Page 25 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00168 | 6.20 Diagnosis: CVS120 shall be applied (Ref 14.12).6.20 Diagnosis: CVS120 shall be applied (Ref 14.12). | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 25 | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 25 Document section 3299216_1 > Page 25 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00169 | 6.21 Cyber Security: Cybersecurity shall be considered through a separate process with the la...6.21 Cyber Security: Cybersecurity shall be considered through a separate process with the latest Traton workflow in mind. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 25 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | Cybersecurity requirement handling | None | High | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 25 Document section 3299216_1 > Page 25 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Cybersecurity requirement handling | Interface: None | SSR: SSR-CON-001 |
| Req.ID-Description-6.22.1 | Req.ID Description 6.22.1 Wrong rotation direction 6.22.2 Short circuit / open load on the ph...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 | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 25 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 25 Document section 3299216_1 > Page 25 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00171 | P 1 Page 6.22.4 Positions sensor short circuit / open load (if used) 6.22.5 Watchdog error 6....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 | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 26 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 26 Document section 3299216_1 > Page 26 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00172 | P 1 Page 6.23 Validation and Invalidation: The reported ESD must be able to be validated and...P 1 Page 6.23 Validation and Invalidation: The reported ESD must be able to be validated and invalidated. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 27 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 27 Document section 3299216_1 > Page 27 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-VV-001 |
| REQ-AUTO-00173 | 6.24 Diagnosis tracking: The gearbox control unit(TCU) shall be responsible for setting DTCs...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 27 | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 27 Document section 3299216_1 > Page 27 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ-AUTO-00174 | If higher resolution is required for the supplier to properly troubleshoot any individual occ...If higher resolution is required for the supplier to properly troubleshoot any individual occurrence, then the ECA is responsible for storing these parameters internally. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 27 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 27 Document section 3299216_1 > Page 27 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-003 |
| REQ-AUTO-00175 | Internally stored parameters may be accessible only using supplier defined tools .Internally stored parameters may be accessible only using supplier defined tools . | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 27 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | OEM/Customer Review Interface | Low | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 27 Document section 3299216_1 > Page 27 Supplier rationale Source classifies this as Constraint (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: None |
| REQ-AUTO-00176 | 6.25 Data logging: Any data logged or stored shall be agreed upon together with Traton.6.25 Data logging: Any data logged or stored shall be agreed upon together with Traton. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 27 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 27 Document section 3299216_1 > Page 27 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00177 | 6.26 Data storage: When storing data in the device, the supplier shall take measures to preve...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 27 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces; OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 27 Document section 3299216_1 > Page 27 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces; OEM/Customer Review Interface | SSR: SSR-COM-002 |
| REQ-AUTO-00178 | The supplier shall also ensure that systems are in place that ensure that data corruption is...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 27 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 27 Document section 3299216_1 > Page 27 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-007 |
| REQ-AUTO-00179 | 6.27 Calibration: There shall only be one calibration set of the ECA that is delivered to Tra...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 27 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 27 Document section 3299216_1 > Page 27 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00180 | 6.28 Reset: It shall be possible to reset the ECA application with a power off/on cycle after...6.28 Reset: It shall be possible to reset the ECA application with a power off/on cycle after all functional safety events. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 27 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 27 Document section 3299216_1 > Page 27 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00181 | ID General electrical requirements 7.1 The electrical design must ensure that an internal sho...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 28 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 28 Document section 3299216_1 > Page 28 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00182 | 7.2 Short circuit protection shall be implemented by hardware.7.2 Short circuit protection shall be implemented by hardware. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 28 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 28 Document section 3299216_1 > Page 28 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-HW-001 |
| REQ-AUTO-00183 | 7.3 A safe boot sequence must be set to prevent unwanted or undefined behavior during or afte...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 28 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 28 Document section 3299216_1 > Page 28 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00184 | 7.4 A safe memory read/write sequence must also be implemented during actuator movement, in o...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 28 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 28 Document section 3299216_1 > Page 28 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-HW-001 |
| Req.ID-Connector-Requirements-7.5 | Req.ID Connector Requirements 7.5 All external electrical connectors shall be geometrically c...Req.ID Connector Requirements 7.5 All external electrical connectors shall be geometrically coded. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 28 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 28 Document section 3299216_1 > Page 28 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-HW-001 |
| REQ-AUTO-00186 | If internal components are included in repair kits, the internal electrical connectors shall...If internal components are included in repair kits, the internal electrical connectors shall also be geometrically coded. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 28 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | High | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 28 Document section 3299216_1 > Page 28 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00187 | 7.8 ECU tab headers shall comply with TB1787.(Ref 14.6) 7.9 ECU tab headers shall be made of...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 28 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 28 Document section 3299216_1 > Page 28 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-HW-001 |
| REQ-AUTO-00188 | All power used by the ECA shall be taken from this battery connection.All power used by the ECA shall be taken from this battery connection. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 29 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 29 Document section 3299216_1 > Page 29 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00189 | The ground shall not be DC connected to the ECA housing.The ground shall not be DC connected to the ECA housing. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 29 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 29 Document section 3299216_1 > Page 29 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00190 | 7.17 Umax: - - 32/36/48 A Specific test relations TBD 7.18 Umin: 16 - - V CVS41 limits may go...7.17 Umax: - - 32/36/48 A Specific test relations TBD 7.18 Umin: 16 - - V CVS41 limits may go below this value. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 29 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 29 Document section 3299216_1 > Page 29 Supplier rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00191 | 7.23 Quiescent current: According to CVS41 (Ref 14.2), must be met independent of input and o...7.23 Quiescent current: According to CVS41 (Ref 14.2), must be met independent of input and output conditions. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 30 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 30 Document section 3299216_1 > Page 30 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00192 | It shall be used to control the power up sequence to the µP.It shall be used to control the power up sequence to the µP. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 31 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 31 Document section 3299216_1 > Page 31 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00193 | The Wake-up signal shall also be connected to a digital input on the µP.The Wake-up signal shall also be connected to a digital input on the µP. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 31 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 31 Document section 3299216_1 > Page 31 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-00194 | Special precautions shall be taken to prevent direct connection between Wake-up and 30 in cas...Special precautions shall be taken to prevent direct connection between Wake-up and 30 in case of a single failure. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 31 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 31 Document section 3299216_1 > Page 31 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00195 | After the wake-up line goes to high state: The ECA shall communicate on the CAN line within 2...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 31 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 31 Document section 3299216_1 > Page 31 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-00196 | After movement and reset, the ECA shall communicate on the CAN line within 250ms After moveme...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 31 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 31 Document section 3299216_1 > Page 31 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-00197 | Definition ready to open clutch: The actuator position shall be between FCCP and FCCP -3mm an...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 31 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 31 Document section 3299216_1 > Page 31 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00198 | Redundancies due improper shutdown shall be aligned with Traton.Redundancies due improper shutdown shall be aligned with Traton. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 31 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 31 Document section 3299216_1 > Page 31 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00199 | If a signal for disengaging the clutch is received the ECA shall actuate the request regardle...If a signal for disengaging the clutch is received the ECA shall actuate the request regardless of CAN-request. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 33 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 33 Document section 3299216_1 > Page 33 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-00200 | Any watchdog circuit shall have no influence on the CAN bus.Any watchdog circuit shall have no influence on the CAN bus. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 34 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 34 Document section 3299216_1 > Page 34 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-00201 | The CAN front end shall be designed to comply with TB1905 (Ref 14.3), with the following addi...The CAN front end shall be designed to comply with TB1905 (Ref 14.3), with the following additional information in this chapter. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 34 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 34 Document section 3299216_1 > Page 34 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-00202 | 7.35 The controller and transceiver shall be CAN FD ready.7.35 The controller and transceiver shall be CAN FD ready. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 34 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 34 Document section 3299216_1 > Page 34 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-00203 | 7.36 Termination resistance: - 2 x 60 - Ω 1% resistors shall be used 7.37 Baud rate: 250 500...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 34 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 34 Document section 3299216_1 > Page 34 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-UPD-001 |
| REQ-AUTO-00204 | ID Requirements 7.39 Note: The layout shall always be present on the PCB and the supplier mus...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 35 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces; OEM/Customer Review Interface | High | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 35 Document section 3299216_1 > Page 35 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces; OEM/Customer Review Interface | SSR: SSR-COM-002 |
| REQ-AUTO-00205 | The components shall not be populated by default.The components shall not be populated by default. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 35 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 35 Document section 3299216_1 > Page 35 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00206 | The CAN front end shall be designed to comply with TB1905.The CAN front end shall be designed to comply with TB1905. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 35 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 35 Document section 3299216_1 > Page 35 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-00207 | The quality of the wire bonding and position shall be properly analyzed.The quality of the wire bonding and position shall be properly analyzed. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 36 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 36 Document section 3299216_1 > Page 36 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00208 | The material shall be lead free and of ”high temperatures solder type”.The material shall be lead free and of ”high temperatures solder type”. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 36 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 36 Document section 3299216_1 > Page 36 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00209 | The melting point of the soldering material and the composition of the soldering material sha...The melting point of the soldering material and the composition of the soldering material shall be declared by supplier. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 36 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 36 Document section 3299216_1 > Page 36 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-003 |
| REQ-AUTO-00210 | The PCB must be supported and must not bent in any direction during the process.The PCB must be supported and must not bent in any direction during the process. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 36 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 36 Document section 3299216_1 > Page 36 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-009 |
| REQ-AUTO-00211 | Conformal coating or lacquer shall cover the entire PCB and all solder joints.Conformal coating or lacquer shall cover the entire PCB and all solder joints. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 36 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 36 Document section 3299216_1 > Page 36 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00212 | The layout of the PCB, including component placement, shall take the applying of conformal co...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 36 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | High | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 36 Document section 3299216_1 > Page 36 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-00213 | shall be specified in the initial offer.shall be specified in the initial offer. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 36 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 36 Document section 3299216_1 > Page 36 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00214 | The conformal coating process and materials shall apply to the latest versions of IPC/EIA J-S...The conformal coating process and materials shall apply to the latest versions of IPC/EIA J-STD-001 (with applicable standards as e.g. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 36 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 36 Document section 3299216_1 > Page 36 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-009 |
| REQ-AUTO-00215 | HDBK-001, IPC-CC-830 and HDBK-830) and the visual appearance of the final coating shall be co...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 36 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 36 Document section 3299216_1 > Page 36 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00216 | Water based and silicone lacquers shall not be used.Water based and silicone lacquers shall not be used. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 36 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 36 Document section 3299216_1 > Page 36 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00217 | 7.45 Ventilation: The air inside the electronics enclosure shall be ventilated with the use o...7.45 Ventilation: The air inside the electronics enclosure shall be ventilated with the use of a membrane. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 36 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 36 Document section 3299216_1 > Page 36 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00218 | The following requirements shall be fulfilled: The unit shall withstand the salt-spray enviro...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 36 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 36 Document section 3299216_1 > Page 36 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00219 | The membrane shall be placed so that it is protected against blunt force, falling dust and dr...The membrane shall be placed so that it is protected against blunt force, falling dust and dripping salt-water. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 36 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 36 Document section 3299216_1 > Page 36 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00220 | The design shall be made to prevent accumulation of water on top of the membrane, or in the c...The design shall be made to prevent accumulation of water on top of the membrane, or in the cavity of the membrane. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 36 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 36 Document section 3299216_1 > Page 36 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00221 | 7.46 Forbidden components: BGA capsule in any form must not be used.7.46 Forbidden components: BGA capsule in any form must not be used. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 36 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 36 Document section 3299216_1 > Page 36 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00222 | Tantalum capacitors must not be used Serial resistors on power supply circuits must not be used.Tantalum capacitors must not be used Serial resistors on power supply circuits must not be used. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 36 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 36 Document section 3299216_1 > Page 36 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00223 | 8.3 The clutch actuator shall withstand 6 500 000 actuations with the test cycle described in...8.3 The clutch actuator shall withstand 6 500 000 actuations with the test cycle described in Appendix B. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 38 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 38 Document section 3299216_1 > Page 38 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00224 | 8.4 Six consecutive units shall run past 6.5M actuations at the supplier, and continue to end...8.4 Six consecutive units shall run past 6.5M actuations at the supplier, and continue to end of life. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 38 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 38 Document section 3299216_1 > Page 38 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-LIFE-002 |
| REQ-AUTO-00225 | Three consecutive units shall run past 6.5M actuations at Scania, and continue to end of life.Three consecutive units shall run past 6.5M actuations at Scania, and continue to end of life. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 38 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 38 Document section 3299216_1 > Page 38 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-LIFE-002 |
| REQ-AUTO-00226 | 8.5 The ECA must be maintenance free over the whole life time.8.5 The ECA must be maintenance free over the whole life time. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 38 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 38 Document section 3299216_1 > Page 38 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00227 | 8.6 Failure rate for ECU and electronics shall be less than: 0ppm @ “0” km 200ppm/year during...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 38 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | High | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 38 Document section 3299216_1 > Page 38 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-HW-001 |
| REQ-AUTO-00228 | Spare parts or repair kits shall be defined together in agreement.Spare parts or repair kits shall be defined together in agreement. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 38 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 38 Document section 3299216_1 > Page 38 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-LIFE-002 |
| REQ-AUTO-00229 | 4.17) shall be provided as a spare part.4.17) shall be provided as a spare part. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 38 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 38 Document section 3299216_1 > Page 38 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-LIFE-002 |
| REQ-AUTO-00230 | 8.9 In a situation where the ECA has jammed, and is holding the clutch open, it shall be poss...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 38 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 38 Document section 3299216_1 > Page 38 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00231 | ID Recycling and environmental impact 9.1 The ECA shall fulfil the requirements stated in STD...ID Recycling and environmental impact 9.1 The ECA shall fulfil the requirements stated in STD3868. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 39 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 39 Document section 3299216_1 > Page 39 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00232 | Out of a recycling and environmental perspective the following standards shall be taken under...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 39 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 39 Document section 3299216_1 > Page 39 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-003 |
| REQ-AUTO-00233 | The different parts of the housing shall be marked according to material content.The different parts of the housing shall be marked according to material content. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 39 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 39 Document section 3299216_1 > Page 39 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-004 |
| REQ-AUTO-00234 | The ECA shall be lead free.The ECA shall be lead free. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 39 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 39 Document section 3299216_1 > Page 39 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-004 |
| REQ-AUTO-00235 | ID ADR Requirements 9.2 All included parts shall fulfil applicable sections of Part 9 in Anne...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 39 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 39 Document section 3299216_1 > Page 39 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-004 |
| REQ-AUTO-00236 | For type approval, the vehicle and its components shall comply with ECE Regulation No.For type approval, the vehicle and its components shall comply with ECE Regulation No. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 39 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | OEM/Customer Review Interface | High | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 39 Document section 3299216_1 > Page 39 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-004 |
| REQ-AUTO-00237 | P 1 Page 10 Environmental and electrical testing 10.1 The ECA must fulfil the general require...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). | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 40 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 40 Document section 3299216_1 > Page 40 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-004 |
| REQ-AUTO-00238 | 10.2 The ECA must not be dependent on software for protection against requirements stated in...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). | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 40 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 40 Document section 3299216_1 > Page 40 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00239 | CAN communication shall not be affected.CAN communication shall not be affected. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 40 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Low | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 40 Document section 3299216_1 > Page 40 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-00240 | Memory functions shall remain Class A.Memory functions shall remain Class A. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 40 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 40 Document section 3299216_1 > Page 40 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-HW-001 |
| REQ-AUTO-00241 | Accepted behaviour in this case shall be agreed upon between Traton and Supplier.Accepted behaviour in this case shall be agreed upon between Traton and Supplier. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 40 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 40 Document section 3299216_1 > Page 40 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-004 |
| REQ-AUTO-00242 | P 1 Page 10.4 For this unit, the following definitions of test procedure I and test procedure...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 41 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 41 Document section 3299216_1 > Page 41 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-004 |
| REQ-AUTO-00243 | This test shall be performed before and after exposure.This test shall be performed before and after exposure. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 41 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 41 Document section 3299216_1 > Page 41 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-004 |
| REQ-AUTO-00244 | Test procedure I (See Figure 17 - Test procedure I) shall at least contain: - Full stroke to...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 41 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 41 Document section 3299216_1 > Page 41 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00245 | This test shall be possible to perform during exposure.This test shall be possible to perform during exposure. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 41 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 41 Document section 3299216_1 > Page 41 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-004 |
| REQ-AUTO-00246 | Reduced versions of test procedure II may be agreed and used during various tests.Reduced versions of test procedure II may be agreed and used during various tests. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 41 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 41 Document section 3299216_1 > Page 41 Supplier rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| 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...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 43 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 43 Document section 3299216_1 > Page 43 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00248 | tab headers) shall be made of self- extinguishing materials (i.e.tab headers) shall be made of self- extinguishing materials (i.e. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 44 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 44 Document section 3299216_1 > Page 44 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-004 |
| 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...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 47 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | High | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 47 Document section 3299216_1 > Page 47 Supplier rationale Source classifies this as Architecture driver (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00250 | Y 10.7.28 CVS46 §5.2 Vehicle test RE: Emitted interference of the complete vehicle Y 10.7.29...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 | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 47 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 47 Document section 3299216_1 > Page 47 Supplier rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00251 | P 1 Page 11 Functional safety The ECA is a part of a safety critical system and shall be hand...P 1 Page 11 Functional safety The ECA is a part of a safety critical system and shall be handled as such. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 49 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 49 Document section 3299216_1 > Page 49 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-004 |
| REQ-AUTO-00252 | The ECA shall therefore be developed and implemented in accordance with the objectives and re...The ECA shall therefore be developed and implemented in accordance with the objectives and requirements of ISO 26262 "Road vehicles - Functional Safety". | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 49 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 49 Document section 3299216_1 > Page 49 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-009 |
| REQ-AUTO-00253 | The supplier shall analyse risks of individua l HW and SW components, mechanics, and any othe...The supplier shall analyse risks of individua l HW and SW components, mechanics, and any other technologies, independently of the scope of ISO 26262. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 49 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | High | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 49 Document section 3299216_1 > Page 49 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-009 |
| REQ-AUTO-00254 | For this purpose possible causes must be systematically identified.For this purpose possible causes must be systematically identified. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 49 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 49 Document section 3299216_1 > Page 49 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-004 |
| REQ-AUTO-00255 | For these analyses at least the methods in ISO 26262 shall be applied.For these analyses at least the methods in ISO 26262 shall be applied. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 49 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 49 Document section 3299216_1 > Page 49 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-009 |
| REQ-AUTO-00256 | ID Verification methods 12.1 Conformance to Requirement Specification A1 The supplier must do...ID Verification methods 12.1 Conformance to Requirement Specification A1 The supplier must do conformance test of all external and internal I/O. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 50 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 50 Document section 3299216_1 > Page 50 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-VV-001 |
| REQ-AUTO-00257 | This test must verify that all internal and external I/O fulfils the requirements in this spe...This test must verify that all internal and external I/O fulfils the requirements in this specification. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 50 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 50 Document section 3299216_1 > Page 50 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-004 |
| REQ-AUTO-00258 | A2 The supplier must perform full DV (Design Verification at B-sample level) and full PV (Pro...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 50 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 50 Document section 3299216_1 > Page 50 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-VV-001 |
| REQ-AUTO-00259 | the suppler must carry out two full test rounds according to the Traton test requirements.the suppler must carry out two full test rounds according to the Traton test requirements. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 50 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 50 Document section 3299216_1 > Page 50 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-004 |
| REQ-AUTO-00260 | Additional tests initiated and performed by the supplier must be discussed with Traton.Additional tests initiated and performed by the supplier must be discussed with Traton. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 50 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 50 Document section 3299216_1 > Page 50 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-004 |
| REQ-AUTO-00261 | A3 The supplier must test the connectors according to TB1787.A3 The supplier must test the connectors according to TB1787. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 50 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 50 Document section 3299216_1 > Page 50 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-004 |
| REQ-AUTO-00262 | A4 The supplier must do EMC tests with the unit alone.A4 The supplier must do EMC tests with the unit alone. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 50 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 50 Document section 3299216_1 > Page 50 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-004 |
| REQ-AUTO-00263 | The supplier must certify the ECA according to UN ECE R10 (EMC), according to the latest revi...The supplier must certify the ECA according to UN ECE R10 (EMC), according to the latest revision with all amendments. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 50 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 50 Document section 3299216_1 > Page 50 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-004 |
| REQ-AUTO-00264 | A5 The supplier must check that both prototypes and serial units fulfil the dimension require...A5 The supplier must check that both prototypes and serial units fulfil the dimension requirement according to any relevant Traton supplied drawings. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 50 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 50 Document section 3299216_1 > Page 50 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-004 |
| REQ-AUTO-00265 | A6 All prototypes and serial ECA’s shall fulfil requirements according to TB1822, IPC/EIA J-S...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 50 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 50 Document section 3299216_1 > Page 50 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-004 |
| REQ-AUTO-00266 | 12.3 Testability The supplier of the unit must write software to enable his own testing of th...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 50 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 50 Document section 3299216_1 > Page 50 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-007 |
| REQ-AUTO-00267 | However, dividing sample phases into several generations must be agreed upon between Traton a...However, dividing sample phases into several generations must be agreed upon between Traton and the supplier. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 51 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 51 Document section 3299216_1 > Page 51 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-004 |
| REQ-AUTO-00268 | All samples shall be functionally tested before sent to Traton.All samples shall be functionally tested before sent to Traton. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 51 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 51 Document section 3299216_1 > Page 51 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-004 |
| REQ-AUTO-00269 | Deviations shall be reported as a part of the sample delivery.Deviations shall be reported as a part of the sample delivery. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 51 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 51 Document section 3299216_1 > Page 51 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-004 |
| REQ-AUTO-00270 | Dimensional checks shall be performed for B and C-samples prior to delivery to Traton.Dimensional checks shall be performed for B and C-samples prior to delivery to Traton. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 51 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 51 Document section 3299216_1 > Page 51 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-004 |
| REQ-AUTO-00271 | The supplier must use the sample denominations requested by Traton.The supplier must use the sample denominations requested by Traton. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 51 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 51 Document section 3299216_1 > Page 51 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-004 |
| REQ-AUTO-00272 | Unless otherwise stated, valid version is the latest available as of 1st May 2026.Unless otherwise stated, valid version is the latest available as of 1st May 2026. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 52 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 52 Document section 3299216_1 > Page 52 Supplier rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00273 | P 1 Page Appendix B – Life length test The life time testing of the ECA shall consist of 6500...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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 57 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 57 Document section 3299216_1 > Page 57 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| req-5.1 | The full strokes should be performed within 180 ms, as specified in req 5.1 and 5.2.The full strokes should be performed within 180 ms, as specified in req 5.1 and 5.2. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 57 | Needs Internal Review | Needs internal review. Confirm whether this should-level requirement is in the committed baseline. | No customer action until supplier review is complete. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 57 Document section 3299216_1 > Page 57 Supplier rationale Non-mandatory wording; baseline inclusion not yet confirmed. Implementation approach Decide baseline inclusion internally, then issue an Accept/Partial position. Acceptance condition Internal baseline decision recorded. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-009 |
| REQ-AUTO-00275 | Between the two movements the actuator should remain in the fully disengaged position.Between the two movements the actuator should remain in the fully disengaged position. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 57 | Needs Internal Review | Needs internal review. Confirm whether this should-level requirement is in the committed baseline. | No customer action until supplier review is complete. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 57 Document section 3299216_1 > Page 57 Supplier rationale Non-mandatory wording; baseline inclusion not yet confirmed. Implementation approach Decide baseline inclusion internally, then issue an Accept/Partial position. Acceptance condition Internal baseline decision recorded. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00276 | After the complete engagement the actuator should remain in this position until the next dise...After the complete engagement the actuator should remain in this position until the next disengagement is requested. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 57 | Needs Internal Review | Needs internal review. Confirm whether this should-level requirement is in the committed baseline. | No customer action until supplier review is complete. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 57 Document section 3299216_1 > Page 57 Supplier rationale Non-mandatory wording; baseline inclusion not yet confirmed. Implementation approach Decide baseline inclusion internally, then issue an Accept/Partial position. Acceptance condition Internal baseline decision recorded. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00277 | • A function test rig shall be used for function tests between intervals • At 6.25M cycles a...• 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. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 59 | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 59 Document section 3299216_1 > Page 59 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00278 | This needs to be checked with the first test run and if necessary the test cycle used in prof...This needs to be checked with the first test run and if necessary the test cycle used in profile B needs to be changed. | customer-input/pdf/3299216_1.pdf | 3299216_1 > Page 61 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/3299216_1.pdf / page 61 Document section 3299216_1 > Page 61 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00279 | TRATON Software Update Variant 2 (SUV2) sequence Foreword This Commercial Vehicle Standard (“...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 1 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 1 Document section CVS123-2 > Page 1 Supplier rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00280 | Any review of this CVS123-2 shall only be done in agreement with the involved TRATON Group co...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”. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 1 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 1 Document section CVS123-2 > Page 1 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-009 |
| REQ-AUTO-00281 | The User shall apply the latest version of this CVS123-2.The User shall apply the latest version of this CVS123-2. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 1 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 1 Document section CVS123-2 > Page 1 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-004 |
| REQ-AUTO-00282 | SUV2_INFO 7 The reason to why an ECU must implement two or more diagnostic servers is that it...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 4 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | Diagnostic security | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 4 Document section CVS123-2 > Page 4 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Diagnostic security | Interface: None | SSR: SSR-RBAC-001 |
| REQ-AUTO-00283 | SUV2_INFO 8 It should be noted that a single server view is not completely achievable and tha...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 4 | Needs Internal Review | Needs internal review. Confirm whether this should-level requirement is in the committed baseline. | No customer action until supplier review is complete. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 4 Document section CVS123-2 > Page 4 Supplier rationale Non-mandatory wording; baseline inclusion not yet confirmed. Implementation approach Decide baseline inclusion internally, then issue an Accept/Partial position. Acceptance condition Internal baseline decision recorded. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00284 | Clients may prefer to implement programming support using other service parameter values or e...Clients may prefer to implement programming support using other service parameter values or even another set of programming steps than | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 4 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 4 Document section CVS123-2 > Page 4 Supplier rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00285 | For this reason, only the server is required to support the specified sequence.For this reason, only the server is required to support the specified sequence. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 5 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 5 Document section CVS123-2 > Page 5 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00286 | Application data module (Calibration data) Contains a variant-specific set of parameter value...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 6 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 6 Document section CVS123-2 > Page 6 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00287 | It must be clearly separated from the application software.It must be clearly separated from the application software. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 6 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 6 Document section CVS123-2 > Page 6 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00288 | For this reason, it is located in a separate memory area and must also be erasable and progra...For this reason, it is located in a separate memory area and must also be erasable and programmable independently of the application software. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 6 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 6 Document section CVS123-2 > Page 6 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00289 | Application software module Contains all vehicle functions required for the normal server ope...Application software module Contains all vehicle functions required for the normal server operation. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 6 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 6 Document section CVS123-2 > Page 6 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00290 | All software parts required for the reprogramming like CAN driver, network layer, diagnostic...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 6 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | Diagnostic security | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 6 Document section CVS123-2 > Page 6 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Diagnostic security | Interface: None | SSR: SSR-RBAC-001 |
| REQ-AUTO-00291 | shall be implemented in the boot software code.shall be implemented in the boot software code. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 6 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 6 Document section CVS123-2 > Page 6 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00292 | The value of this variable (and C2, see below) may be used by the boot manager to determine w...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 6 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 6 Document section CVS123-2 > Page 6 Supplier rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0051 | Internal Page 26 (90) Diagnostics Service Diag Safe state check Application Boot loader Trans...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). | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 6 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 6 Document section CVS123-2 > Page 6 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00294 | The value of this variable (and C1, see above) may be used by the boot manager to determine w...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 6 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 6 Document section CVS123-2 > Page 6 Supplier rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0051 | Internal Page 26 (90) Diagnostics Service Diag Safe state check Application Boot loader Trans...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). | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 6 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 6 Document section CVS123-2 > Page 6 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00296 | The value of this variable may be used by the application to determine whether or not initial...The value of this variable may be used by the application to determine whether or not initialization is required. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 6 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 6 Document section CVS123-2 > Page 6 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00297 | Satisfied programming precondition A programming precondition agreed between supplier and veh...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 7 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 7 Document section CVS123-2 > Page 7 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-UPD-002 |
| REQ-AUTO-00298 | Tester System that controls functions such as test, inspection, monitoring, or diagnosis of a...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 | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 7 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 7 Document section CVS123-2 > Page 7 Supplier rationale Source classifies this as Cybersecurity control (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00299 | Page 9 4 General requirements SUV2_REQ 1 The implementation of the client and the server shal...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 9 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | Diagnostic security | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 9 Document section CVS123-2 > Page 9 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Diagnostic security | Interface: None | SSR: SSR-RBAC-001 |
| REQ-AUTO-00300 | Requirements in (CVS124) which are not explicitly stated to apply to the application only (su...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 9 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 9 Document section CVS123-2 > Page 9 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-BOOT-001 |
| REQ-AUTO-00301 | SUV2_REQ 2 All deviations from this specification shall be agreed with the applicable vehicle...SUV2_REQ 2 All deviations from this specification shall be agreed with the applicable vehicle manufacturer(s). | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 9 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 9 Document section CVS123-2 > Page 9 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-004 |
| REQ-AUTO-00302 | SUV2_REQ 3 The programming requirements in this specification shall apply to the programming...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 9 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 9 Document section CVS123-2 > Page 9 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-BOOT-001 |
| REQ-AUTO-00303 | SUV2_REQ 4 If as a deviation with respect to SUV2_REQ 3 an ECU will not support boot loader r...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 9 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 9 Document section CVS123-2 > Page 9 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-BOOT-002 |
| REQ-AUTO-00304 | A SW or HW protection mechanism shall be used to protect the software from being accidentally...A SW or HW protection mechanism shall be used to protect the software from being accidentally erased or overwritten. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 9 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 9 Document section CVS123-2 > Page 9 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00305 | If the microcontroller supports HW protection, this shall be used.If the microcontroller supports HW protection, this shall be used. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 9 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 9 Document section CVS123-2 > Page 9 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-004 |
| REQ-AUTO-00306 | SUV2_REQ 5 The server shall support programming of all application software and application d...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 9 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. | OP-004 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 9 Document section CVS123-2 > Page 9 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-UPD-003 |
| REQ-AUTO-00307 | SUV2_REQ 6 Programming of a subset of modules may lead to that the consistency check at the e...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 9 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 9 Document section CVS123-2 > Page 9 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-UPD-001 |
| REQ-AUTO-00308 | SUV2_REQ 7 Boot loader updating according to this specification shall be supported during dev...SUV2_REQ 7 Boot loader updating according to this specification shall be supported during development, from A-samples and onwards. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 9 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 9 Document section CVS123-2 > Page 9 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-BOOT-003 |
| REQ-AUTO-00309 | SUV2_REQ 8 A server shall be programmable according to this specification (i.e., not only usi...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 9 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | OEM/Customer Review Interface | Low | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 9 Document section CVS123-2 > Page 9 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-DIAG-003 |
| REQ-AUTO-00310 | SUV2_REQ 9 A server shall be programmable while integrated in the vehicle network and as a st...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 9 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | Diagnostic security | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 9 Document section CVS123-2 > Page 9 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Diagnostic security | Interface: None | SSR: SSR-RBAC-001 |
| REQ-AUTO-00311 | Page 10 SUV2_REQ 10 The solution for maintaining/reorganizing data (EEPROM data, operational...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 10 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 10 Document section CVS123-2 > Page 10 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-UPD-003 |
| REQ-AUTO-00312 | 4.1 Documentation requirements SUV2_REQ 11 The supplier shall provide, for each committed sof...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 10 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 10 Document section CVS123-2 > Page 10 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-UPD-003 |
| REQ-AUTO-00313 | SUV2_REQ 12 Normal and worst-case performance values shall be documented for: • Total time fo...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). | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 10 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. | OP-004 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 10 Document section CVS123-2 > Page 10 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-UPD-003 |
| REQ-AUTO-00314 | SUV2_REQ 13 The supplier shall document the versioning concept for supplier specific DIDs.SUV2_REQ 13 The supplier shall document the versioning concept for supplier specific DIDs. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 10 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 10 Document section CVS123-2 > Page 10 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-004 |
| REQ-AUTO-00315 | 4.2 Software architecture requirements SUV2_REQ 14 System name (DID 0xF197), diagnostic addre...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”. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 10 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | Diagnostic security | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 10 Document section CVS123-2 > Page 10 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Diagnostic security | Interface: None | SSR: SSR-RBAC-001 |
| REQ-AUTO-00316 | When this module is programmed the parameter values in it shall override default parameter va...When this module is programmed the parameter values in it shall override default parameter values persisted in the boot loader software module. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 10 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 10 Document section CVS123-2 > Page 10 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-BOOT-001 |
| REQ-AUTO-00317 | It should be possible to reuse the generic bootloader for future currently unknown purposes/a...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 10 | Needs Customer Clarification | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. | OP-004 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 10 Document section CVS123-2 > Page 10 Supplier rationale Flagged customer_clarification_needed=yes during extraction. Implementation approach Hold implementation; raise an open point and a clarification question. Acceptance condition Customer answers the linked open point. Responsibility assumption OEM / Customer Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00318 | SUV2_REQ 15 When the boot loader software in an ECU has not yet been parameterized (a boot pa...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 | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 10 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | Diagnostic security | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 10 Document section CVS123-2 > Page 10 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Diagnostic security | Interface: None | SSR: SSR-RBAC-001 |
| REQ-AUTO-00319 | SUV2_REQ 16 Default values for EOL parameters shall be implemented in a dedicated application...SUV2_REQ 16 Default values for EOL parameters shall be implemented in a dedicated application data module, referred to as “EOL parameters module”. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 11 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 11 Document section CVS123-2 > Page 11 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00320 | SUV2_REQ 17 The partitioning of the ECU software into modules shall be discussed and agreed w...SUV2_REQ 17 The partitioning of the ECU software into modules shall be discussed and agreed with the vehicle manufacturer. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 11 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 11 Document section CVS123-2 > Page 11 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-007 |
| REQ-AUTO-00321 | 4.3 Software distribution requirements SUV2_REQ 19 A software released for integration test,...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 11 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm production/debug hardening expectations (debug lock, secure end-of-line, developer-access policy). | OP-008 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 11 Document section CVS123-2 > Page 11 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DAI-003 |
| REQ-AUTO-00322 | SUV2_REQ 20 Flash files delivered from the supplier shall never have to be modified by the ve...SUV2_REQ 20 Flash files delivered from the supplier shall never have to be modified by the vehicle manufacturer. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 11 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 11 Document section CVS123-2 > Page 11 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-UPD-001 |
| REQ-AUTO-00323 | SUV2_REQ 182 The supplier shall deliver the necessary information to verify the integrity of...SUV2_REQ 182 The supplier shall deliver the necessary information to verify the integrity of the flash files. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 11 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 11 Document section CVS123-2 > Page 11 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-UPD-001 |
| REQ-AUTO-00324 | SUV2_INFO 129 In case the supplier delivers encrypted flash files to the vehicle manufacturer...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 11 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces; OEM/Customer Review Interface | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 11 Document section CVS123-2 > Page 11 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces; OEM/Customer Review Interface | SSR: SSR-UPD-004 |
| REQ-AUTO-00325 | SUV2_REQ 21 Whether or not the ECU shall be delivered from the supplier to the vehicle manufa...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 11 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 11 Document section CVS123-2 > Page 11 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-007 |
| REQ-AUTO-00326 | SUV2_INFO 130 Regardless of if the ECU will be delivered from the supplier with a pre-program...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 11 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 11 Document section CVS123-2 > Page 11 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-UPD-003 |
| REQ-AUTO-00327 | SUV2_REQ 22 When the application module is pre-programmed by the supplier, ECU and software i...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 11 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 11 Document section CVS123-2 > Page 11 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-007 |
| REQ-AUTO-00328 | Otherwise 0xF187 and 0xF188 shall be set to default values, see CVS124.Otherwise 0xF187 and 0xF188 shall be set to default values, see CVS124. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 11 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 11 Document section CVS123-2 > Page 11 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-004 |
| REQ-AUTO-00329 | Page 12 5 Detailed programming sequence SUV2_REQ 23 Programmable servers shall support the fu...Page 12 5 Detailed programming sequence SUV2_REQ 23 Programmable servers shall support the full programming sequence described in this chapter. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 12 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. | OP-004 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 12 Document section CVS123-2 > Page 12 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-UPD-001 |
| REQ-AUTO-00330 | SUV2_REQ 24 Non-programmable servers shall support the pre-programming and post-programming s...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). | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 12 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. | OP-004 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 12 Document section CVS123-2 > Page 12 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-UPD-001 |
| REQ-AUTO-00331 | SUV2_REQ 25 The programming sequence described in this chapter shall be supported when a vali...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 12 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 12 Document section CVS123-2 > Page 12 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-BOOT-001 |
| REQ-AUTO-00332 | The full set of addressing modes, SPRMIB values and other parameter values that the server sh...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 12 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 12 Document section CVS123-2 > Page 12 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00333 | SUV2_REQ 26 To enable access to diagnostic services in the programming sequence, an authentic...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 12 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | Authentication | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 12 Document section CVS123-2 > Page 12 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Authentication | Interface: None | SSR: SSR-RBAC-002 |
| REQ-AUTO-00334 | SUV2_REQ 27 The server shall receive a diagnostic service authentication (0x29) with SubFunct...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 12 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | Authentication | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 12 Document section CVS123-2 > Page 12 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Authentication | Interface: None | SSR: SSR-RBAC-002 |
| REQ-AUTO-00335 | SUV2_INFO 35 As example, the client may read certificate validity time and/or RBAC configurat...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 14 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 14 Document section CVS123-2 > Page 14 Supplier rationale Source classifies this as Cybersecurity control (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00336 | SUV2_INFO 39 As example, the client may have identified that the RBAC configuration file requ...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 14 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 14 Document section CVS123-2 > Page 14 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00337 | Alternatively, it may be a client strategy to always update certain entities prior to a softw...Alternatively, it may be a client strategy to always update certain entities prior to a software update. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 14 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 14 Document section CVS123-2 > Page 14 Supplier rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00338 | SUV2_INFO 52 Since Link Control is only applicable in production when no application has been...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 15 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | OEM/Customer Review Interface | Low | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 15 Document section CVS123-2 > Page 15 Supplier rationale Source classifies this as Constraint (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: None |
| REQ-AUTO-00339 | SUV2_REQ 28 For the server to verify the integrity of the software, the information to verify...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). | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 16 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 16 Document section CVS123-2 > Page 16 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DAI-003 |
| REQ-AUTO-00340 | SUV2_REQ 29 If the SW to be updated is encrypted, decryption keys shall be available to the s...SUV2_REQ 29 If the SW to be updated is encrypted, decryption keys shall be available to the server before step P1Pro9. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 16 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 16 Document section CVS123-2 > Page 16 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00341 | SUV2_REQ 30 Before the server executes the TransferData service, the server shall check if th...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 16 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 16 Document section CVS123-2 > Page 16 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-SDT-001 |
| REQ_UDS-0051 | Internal Page 26 (90) Diagnostics Service Diag Safe state check Application Boot loader Trans...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). | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 17 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 17 Document section CVS123-2 > Page 17 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00343 | SUV2_INFO 82 Implementation hint: The integrity information may contain parts of memory not p...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 19 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 19 Document section CVS123-2 > Page 19 Supplier rationale Source classifies this as Non-functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00344 | SUV2_INFO 93 If the application was started, it checks if application initialization is requi...SUV2_INFO 93 If the application was started, it checks if application initialization is required. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 20 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 20 Document section CVS123-2 > Page 20 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00345 | If so, the server performs the required checks/reorganization measures for the data structure...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 20 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 20 Document section CVS123-2 > Page 20 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-LOG-002 |
| REQ-AUTO-00346 | SUV2_INFO 94 Implementation hint: The ECU application checks the reprogrammed flag (C3, see p...SUV2_INFO 94 Implementation hint: The ECU application checks the reprogrammed flag (C3, see programming step P1Pro11) to see if application initialization is required. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 20 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 20 Document section CVS123-2 > Page 20 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-UPD-003 |
| REQ-AUTO-00347 | SUV2_INFO 85 As example, the client may have identified that the new software requires an upd...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 20 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 20 Document section CVS123-2 > Page 20 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-004 |
| REQ-AUTO-00348 | Page 21 6 Server reprogramming requirements 6.1 Requirements for servers to support programmi...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 21 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. | OP-004 | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 21 Document section CVS123-2 > Page 21 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-UPD-005 |
| REQ-AUTO-00349 | SUV2_REQ 34 Whether or not the ECU shall support stand-alone programming at the vehicle manuf...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 21 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 21 Document section CVS123-2 > Page 21 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-UPD-002 |
| REQ-AUTO-00350 | SUV2_REQ 35 A server that is running in the application shall respond with the same diagnosti...SUV2_REQ 35 A server that is running in the application shall respond with the same diagnostic address after a switch to boot. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 21 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | Diagnostic security | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 21 Document section CVS123-2 > Page 21 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Diagnostic security | Interface: None | SSR: SSR-RBAC-001 |
| REQ-AUTO-00351 | SUV2_REQ 36 It shall be possible to downgrade server software modules as long as the programm...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 21 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 21 Document section CVS123-2 > Page 21 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00352 | SUV2_REQ 37 Application software and application data modules shall be programmable in any or...SUV2_REQ 37 Application software and application data modules shall be programmable in any order. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 21 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 21 Document section CVS123-2 > Page 21 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00353 | SUV2_REQ 38 The server shall be able to update an individual module independently from any ot...SUV2_REQ 38 The server shall be able to update an individual module independently from any other module. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 21 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 21 Document section CVS123-2 > Page 21 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00354 | SUV2_REQ 39 If the performance requirements SUV2_REQ 62 or SUV2_REQ 63 cannot be met, a compr...SUV2_REQ 39 If the performance requirements SUV2_REQ 62 or SUV2_REQ 63 cannot be met, a compression method shall be implemented. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 21 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 21 Document section CVS123-2 > Page 21 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-004 |
| REQ-AUTO-00355 | SUV2_REQ 40 The LZSS algorithm with a dictionary size of 1 023 bytes or a newer compression/d...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 21 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 21 Document section CVS123-2 > Page 21 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-004 |
| REQ-AUTO-00356 | SUV2_REQ 41 The use of alternative compression/decompression algorithms shall be agreed with...SUV2_REQ 41 The use of alternative compression/decompression algorithms shall be agreed with the vehicle manufacturer. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 21 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 21 Document section CVS123-2 > Page 21 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-004 |
| REQ-AUTO-00357 | SUV2_REQ 42 It shall be possible to program the same software version repeatedly.SUV2_REQ 42 It shall be possible to program the same software version repeatedly. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 21 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 21 Document section CVS123-2 > Page 21 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00358 | SUV2_REQ 43 If at startup the ECU hardware/software is consistent and a programming request i...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 21 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 21 Document section CVS123-2 > Page 21 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-UPD-003 |
| REQ-AUTO-00359 | SUV2_REQ 44 Otherwise if at startup the ECU hardware/software is inconsistent the boot manage...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 21 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 21 Document section CVS123-2 > Page 21 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-BOOT-001 |
| REQ-AUTO-00360 | SUV2_REQ 45 If at startup the boot manager starts and executes the application, the applicati...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 21 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 21 Document section CVS123-2 > Page 21 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00361 | Otherwise if at startup the boot manager starts and executes the boot loader and a valid boot...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 21 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 21 Document section CVS123-2 > Page 21 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-BOOT-003 |
| REQ-AUTO-00362 | Otherwise if no boot parameter module has been successfully programmed, the boot loader shall...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 21 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 21 Document section CVS123-2 > Page 21 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-BOOT-003 |
| REQ-AUTO-00363 | Page 22 SUV2_REQ 46 After reprogramming, the application shall store DIDs F1AB, F1AA, F1A9.Page 22 SUV2_REQ 46 After reprogramming, the application shall store DIDs F1AB, F1AA, F1A9. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 22 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 22 Document section CVS123-2 > Page 22 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-UPD-003 |
| REQ-AUTO-00364 | SUV2_REQ 47 The technical implementation of the programming preconditions shall be agreed bet...SUV2_REQ 47 The technical implementation of the programming preconditions shall be agreed between the supplier and the vehicle manufacturer. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 22 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 22 Document section CVS123-2 > Page 22 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-UPD-001 |
| REQ-AUTO-00365 | SUV2_REQ 48 A programmable server shall guarantee re-programmability within the normal operat...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 22 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 22 Document section CVS123-2 > Page 22 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00366 | SUV2_REQ 49 A server that is restarted for any reason or thrown back to DefaultSession due to...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 22 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 22 Document section CVS123-2 > Page 22 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-UPD-005 |
| REQ-AUTO-00367 | 6.1.1 Boot software description and requirements 6.1.1.1 Boot software general requirements S...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 22 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. | OP-004 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 22 Document section CVS123-2 > Page 22 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-UPD-003 |
| REQ-AUTO-00368 | The causes specified in (ISO14229-1:2020) shall be regarded as examples.The causes specified in (ISO14229-1:2020) shall be regarded as examples. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 22 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 22 Document section CVS123-2 > Page 22 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-004 |
| REQ-AUTO-00369 | SUV2_REQ 51 The server shall be re-programmable (standalone and in the vehicle) regardless of...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 22 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 22 Document section CVS123-2 > Page 22 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00370 | 6.1.1.2 Boot software session requirements SUV2_REQ 52 Diagnostic services support shall be a...6.1.1.2 Boot software session requirements SUV2_REQ 52 Diagnostic services support shall be as per CVS124. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 22 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | Diagnostic security | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 22 Document section CVS123-2 > Page 22 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Diagnostic security | Interface: None | SSR: SSR-RBAC-001 |
| REQ-AUTO-00371 | SUV2_REQ 53 Additionally, the services specified in Table 3 shall be supported.SUV2_REQ 53 Additionally, the services specified in Table 3 shall be supported. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 22 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 22 Document section CVS123-2 > Page 22 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-004 |
| REQ-AUTO-00372 | Non-Def = Any other session than default diagnostic session 6.1.1.3 ECU Identification Data S...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 23 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | Diagnostic security | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 23 Document section CVS123-2 > Page 23 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Diagnostic security | Interface: None | SSR: SSR-RBAC-001 |
| REQ-AUTO-00373 | 6.1.1.4 Performance requirements SUV2_REQ 62 When programmed in the vehicle manufacturer’s pr...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). | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 23 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. | OP-004 | None | OEM/Customer Review Interface | Low | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 23 Document section CVS123-2 > Page 23 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-UPD-003 |
| REQ-AUTO-00374 | SUV2_INFO 106 This does not apply to ECUs for which all software modules are pre-programmed i...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 23 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 23 Document section CVS123-2 > Page 23 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-UPD-003 |
| REQ-AUTO-00375 | SUV2_REQ 63 When programmed in the workshop the total time for programming of all modules sha...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). | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 23 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. | OP-004 | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 23 Document section CVS123-2 > Page 23 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-UPD-003 |
| REQ-AUTO-00376 | 6.1.1.4.1 Server routine access SUV2_REQ 64 The server shall support the routines specified i...6.1.1.4.1 Server routine access SUV2_REQ 64 The server shall support the routines specified in Table 4. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 23 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 23 Document section CVS123-2 > Page 23 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00377 | 7 Diagnostic service requirements 7.1 RequestDownload (0x34) Service SUV2_REQ 65 If the most...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 24 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | Diagnostic security | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 24 Document section CVS123-2 > Page 24 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Diagnostic security | Interface: None | SSR: SSR-RBAC-001 |
| REQ-AUTO-00378 | SUV2_INFO 107 In order to satisfy stability requirements, the erasing of the boot loader may...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 24 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 24 Document section CVS123-2 > Page 24 Supplier rationale Source classifies this as Non-functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00379 | SUV2_REQ 66 If the most recent Erase Memory routine request in the current session was made w...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). | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 24 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 24 Document section CVS123-2 > Page 24 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00380 | SUV2_REQ 67 Once the RequestDownload service has started, only services TesterPresent, ECURes...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 24 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 24 Document section CVS123-2 > Page 24 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SDT-001 |
| REQ-AUTO-00381 | SUV2_REQ 68 If a non-permitted service is requested after the RequestDownload service has sta...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 | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 24 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 24 Document section CVS123-2 > Page 24 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00382 | Page 25 (requestSequenceError) and shall accept programming to proceed from the state at whic...Page 25 (requestSequenceError) and shall accept programming to proceed from the state at which it was executing before this non-permitted service was requested. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 25 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 25 Document section CVS123-2 > Page 25 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-UPD-003 |
| REQ-AUTO-00383 | SUV2_REQ 69 For each received RequestDownload request, the server shall check if there is a V...SUV2_REQ 69 For each received RequestDownload request, the server shall check if there is a VerificationEntry match in SDSC. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 25 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 25 Document section CVS123-2 > Page 25 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-VV-002 |
| REQ-AUTO-00384 | SUV2_REQ 71 The server shall check whether any part of the received data is encrypted or not...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 25 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 25 Document section CVS123-2 > Page 25 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00385 | SUV2_REQ 190 The server shall not execute the new software until it can be verified using rou...SUV2_REQ 190 The server shall not execute the new software until it can be verified using routine 0xFF01. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 25 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 25 Document section CVS123-2 > Page 25 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00386 | 7.1.1 Request SUV2_REQ 72 The server shall support service request formatted according to Tab...7.1.1 Request SUV2_REQ 72 The server shall support service request formatted according to Table 5. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 25 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 25 Document section CVS123-2 > Page 25 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00387 | Page 26 7.1.2 Positive Response SUV2_REQ 73 The server shall support service positive respons...Page 26 7.1.2 Positive Response SUV2_REQ 73 The server shall support service positive response formatted according to Table 6. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 26 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 26 Document section CVS123-2 > Page 26 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00388 | #4 maxNumberOfBlockLength[] = [ byte #1 (MSB) byte #2 ] M 0x0000 – 0xFFFF 7.1.3 Negative Resp...#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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 26 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 26 Document section CVS123-2 > Page 26 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00389 | 7.1.4 Service 0x34 Parameters SUV2_REQ 165 In case a software is encrypted, the server shall...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 26 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 26 Document section CVS123-2 > Page 26 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-VV-003 |
| REQ-AUTO-00390 | SUV2_REQ 166 In case a software is compressed, the server shall decompress the software befor...SUV2_REQ 166 In case a software is compressed, the server shall decompress the software before software hash comparison verification is performed. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 26 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 26 Document section CVS123-2 > Page 26 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-VV-003 |
| REQ-AUTO-00391 | SUV2_REQ 167 The server shall verify the software hash after decryption and/or decompression...SUV2_REQ 167 The server shall verify the software hash after decryption and/or decompression are performed. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 26 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 26 Document section CVS123-2 > Page 26 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00392 | 7.1.4.1 Parameter dataFormatIdentifier SUV2_REQ 75 The server shall support parameter dataFor...7.1.4.1 Parameter dataFormatIdentifier SUV2_REQ 75 The server shall support parameter dataFormatIdentifier formatted according to Table 7. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 26 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 26 Document section CVS123-2 > Page 26 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00393 | Page 27 7.1.4.2 Parameter addressAndLengthFormatIdentifier SUV2_REQ 76 The server shall suppo...Page 27 7.1.4.2 Parameter addressAndLengthFormatIdentifier SUV2_REQ 76 The server shall support parameter addressAndLengthFormatIdentifier formatted according to Table 8. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 27 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 27 Document section CVS123-2 > Page 27 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00394 | Table 8: Service 0x34 addressAndLengthFormatIdentifier Format Bits Description Cvt Values 7 -...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 27 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 27 Document section CVS123-2 > Page 27 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00395 | M 0 7.2 TransferData (0x36) Service 7.2.1 Request SUV2_REQ 78 The server shall support reques...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 27 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 27 Document section CVS123-2 > Page 27 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-SDT-001 |
| REQ-AUTO-00396 | 7.2.2 Positive Response SUV2_REQ 79 The server shall support positive response formatted acco...7.2.2 Positive Response SUV2_REQ 79 The server shall support positive response formatted according to ISO14229-1:2020. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 27 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 27 Document section CVS123-2 > Page 27 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00397 | 7.2.3 Negative Response SUV2_REQ 80 SUV2_REQ 81 If for any reason an error occurs during decr...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 27 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 27 Document section CVS123-2 > Page 27 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00398 | 7.2.4 Service 0x36 Parameters 7.2.4.1 Parameter blockSequenceCounter SUV2_REQ 82 The server s...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 27 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 27 Document section CVS123-2 > Page 27 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-SDT-001 |
| REQ-AUTO-00399 | Page 28 7.2.4.2 Parameter transferRequestParameterRecord SUV2_REQ 83 The server shall support...Page 28 7.2.4.2 Parameter transferRequestParameterRecord SUV2_REQ 83 The server shall support parameter transferRequestParameterRecord formatted according to ISO14229-1:2020. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 28 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 28 Document section CVS123-2 > Page 28 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00400 | 7.3 RequestTransferExit (0x37) Service 7.3.1 Request SUV2_REQ 84 The server shall support req...7.3 RequestTransferExit (0x37) Service 7.3.1 Request SUV2_REQ 84 The server shall support request formatted according to Table 10. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 28 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 28 Document section CVS123-2 > Page 28 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00401 | Table 10: Service 0x37 Request Format Byte No Description Cvt Byte Value 1 RequestTransferExi...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 28 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 28 Document section CVS123-2 > Page 28 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00402 | Table 11: Service 0x37 Positive Response Format Byte No Description Cvt Byte Value 1 RequestT...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 28 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 28 Document section CVS123-2 > Page 28 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00403 | 7.3.4.2 Parameter transferResponseParameterRecord SUV2_REQ 88 The server shall not support tr...7.3.4.2 Parameter transferResponseParameterRecord SUV2_REQ 88 The server shall not support transferResponseParameterRecord parameter. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 28 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 28 Document section CVS123-2 > Page 28 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00404 | 7.4 SecuredDataTranmission (0x84) Service SUV2_REQ 89 The server shall support service 0x84 a...7.4 SecuredDataTranmission (0x84) Service SUV2_REQ 89 The server shall support service 0x84 according to CVS32. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 28 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 28 Document section CVS123-2 > Page 28 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00405 | 7.4.1 Request SUV2_REQ 90 The server shall support request formatted according to ISO14229-1:...7.4.1 Request SUV2_REQ 90 The server shall support request formatted according to ISO14229-1:2020. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 28 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 28 Document section CVS123-2 > Page 28 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00406 | Page 29 7.4.2 Positive Response SUV2_REQ 91 The server shall support positive response format...Page 29 7.4.2 Positive Response SUV2_REQ 91 The server shall support positive response formatted according to ISO14229-1:2020. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 29 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 29 Document section CVS123-2 > Page 29 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00407 | 7.4.3 Negative Response SUV2_REQ 92 SUV2_REQ 93 The server shall support negative response co...7.4.3 Negative Response SUV2_REQ 92 SUV2_REQ 93 The server shall support negative response codes according to CVS32. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 29 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 29 Document section CVS123-2 > Page 29 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00408 | 7.4.4 Service 0x84 Parameters 7.4.4.1 Parameter Administrative Parameter SUV2_REQ 94 The serv...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 29 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 29 Document section CVS123-2 > Page 29 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00409 | 7.4.4.2 Parameter Signature/Encryption Calculation (SIGENCRYPT) SUV2_REQ 95 The server shall...7.4.4.2 Parameter Signature/Encryption Calculation (SIGENCRYPT) SUV2_REQ 95 The server shall support parameter Signature/Encryption Calculation (SIGENCRYPT) according to CVS32. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 29 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 29 Document section CVS123-2 > Page 29 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DAI-004 |
| REQ-AUTO-00410 | 7.4.4.3 Parameter Anti-replay Counter (ANTIREPLAYCNT) SUV2_REQ 96 The server shall support pa...7.4.4.3 Parameter Anti-replay Counter (ANTIREPLAYCNT) SUV2_REQ 96 The server shall support parameter Anti-replay Counter (ANTIREPLAYCNT) according to CVS32. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 29 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 29 Document section CVS123-2 > Page 29 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-COM-006 |
| REQ-AUTO-00411 | 8 Diagnostic Routine Identifier Requirements 8.1 Routine Session and routineControlSupport 8....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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 29 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | Diagnostic security | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 29 Document section CVS123-2 > Page 29 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Diagnostic security | Interface: None | SSR: SSR-RBAC-001 |
| REQ-AUTO-00412 | Non-Def = Any other session than default diagnostic session 8.1.2 Routine routineControlType...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 30 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | Diagnostic security | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 30 Document section CVS123-2 > Page 30 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Diagnostic security | Interface: None | SSR: SSR-RBAC-001 |
| REQ-AUTO-00413 | Table 13: Routine Support per routineControlType RID Name routineControlType startRoutine (0x...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 30 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | Diagnostic security | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 30 Document section CVS123-2 > Page 30 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Diagnostic security | Interface: None | SSR: SSR-RBAC-001 |
| REQ-AUTO-00414 | SUV2_REQ 99 The server shall verify the programmed software module by calculating a checksum...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 30 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 30 Document section CVS123-2 > Page 30 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DAI-003 |
| REQ-AUTO-00415 | SUV2_REQ 100 The pre-calculated checksum shall be provided as part of the data submitted with...SUV2_REQ 100 The pre-calculated checksum shall be provided as part of the data submitted with the TransferData service request. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 30 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 30 Document section CVS123-2 > Page 30 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SDT-001 |
| REQ-AUTO-00416 | Page 31 SUV2_INFO 111 Implementation Hint: The following generator polynomial with the follow...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 31 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 31 Document section CVS123-2 > Page 31 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DAI-004 |
| REQ-AUTO-00417 | Table 15: Routine 0x2202 Request Format Byte Description Cvt Hex #1 RoutineControl Request SI...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 31 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 31 Document section CVS123-2 > Page 31 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-003 |
| REQ-AUTO-00418 | Page 32 8.2.4 Routine 0x2202 Parameters 8.2.4.1 Parameter routineStatus routineResult SUV2_RE...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 32 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 32 Document section CVS123-2 > Page 32 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-003 |
| REQ-AUTO-00419 | SUV2_REQ 106 The server shall respond with a positive response code without erasing memory if...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 32 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 32 Document section CVS123-2 > Page 32 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-SYS-007 |
| REQ-AUTO-00420 | SUV2_INFO 113 In order to satisfy stability requirements, the erasing of the boot loader may...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 32 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 32 Document section CVS123-2 > Page 32 Supplier rationale Source classifies this as Non-functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00421 | SUV2_REQ 107 In case the non volatile memory area is currently hosting a bootloader copy, mea...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 32 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 32 Document section CVS123-2 > Page 32 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-BOOT-002 |
| REQ-AUTO-00422 | SUV2_REQ 108 When the addressAndLengthFormatIdentifier parameter is set to a value > 0x00 the...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). | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 32 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 32 Document section CVS123-2 > Page 32 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-SYS-008 |
| REQ-AUTO-00423 | SUV2_REQ 109 The erasing of memory shall not prevent the client from starting a data transfer...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 32 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 32 Document section CVS123-2 > Page 32 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SDT-001 |
| REQ-AUTO-00424 | Page 33 8.3.1 Routine Request SUV2_REQ 110 The server shall support the routine request accor...Page 33 8.3.1 Routine Request SUV2_REQ 110 The server shall support the routine request according to Table 18. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 33 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 33 Document section CVS123-2 > Page 33 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00425 | 8.3.2 Routine Positive Response SUV2_REQ 111 The server shall support the routine positive re...8.3.2 Routine Positive Response SUV2_REQ 111 The server shall support the routine positive response according to Table 19. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 33 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 33 Document section CVS123-2 > Page 33 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00426 | Page 34 8.3.3 Routine Negative Response SUV2_REQ 112 8.3.4 Routine 0xFF00 Parameters 8.3.4.1...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 34 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 34 Document section CVS123-2 > Page 34 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00427 | E.g., 02, Module 2 (Application SW module) M 0x02 – 0xFF Physical memory range erase: Refer t...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 34 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 34 Document section CVS123-2 > Page 34 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-008 |
| REQ-AUTO-00428 | SUV2_REQ 114 When the addressAndLengthFormatIdentifier is set to 0x01 the defined module to i...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 34 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 34 Document section CVS123-2 > Page 34 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-004 |
| REQ-AUTO-00429 | Table 21: Module to Index Mapping Value Mapped to 0x01 Bootloader 0x02 Application 0x03 Appli...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 34 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. | OP-004 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 34 Document section CVS123-2 > Page 34 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-BOOT-001 |
| REQ-AUTO-00430 | SUV2_REQ 143 This RoutineIdentifier shall be able to execute independent from programming seq...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 35 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 35 Document section CVS123-2 > Page 35 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-UPD-003 |
| REQ-AUTO-00431 | SUV2_REQ 116 The server shall check whether the individual modules are complete and compatibl...SUV2_REQ 116 The server shall check whether the individual modules are complete and compatible with one another. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 35 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 35 Document section CVS123-2 > Page 35 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00432 | In addition, a check shall be made to determine whether the software is compatible with the h...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). | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 35 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 35 Document section CVS123-2 > Page 35 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-008 |
| REQ-AUTO-00433 | SUV2_REQ 117 The method used to check compatibility/consistency shall be determined by the su...SUV2_REQ 117 The method used to check compatibility/consistency shall be determined by the supplier in consultation with the vehicle manufacturer. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 35 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 35 Document section CVS123-2 > Page 35 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-004 |
| REQ-AUTO-00434 | SUV2_REQ 118 The consistency check shall be carried out solely by the server.SUV2_REQ 118 The consistency check shall be carried out solely by the server. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 35 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 35 Document section CVS123-2 > Page 35 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00435 | SUV2_REQ 119 The server shall verify the integrity of the software as a part of the consisten...SUV2_REQ 119 The server shall verify the integrity of the software as a part of the consistency check. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 35 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 35 Document section CVS123-2 > Page 35 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DAI-003 |
| REQ-AUTO-00436 | SUV2_REQ 120 The integrity information shall be supplied to the server before the software is...SUV2_REQ 120 The integrity information shall be supplied to the server before the software is updated. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 35 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 35 Document section CVS123-2 > Page 35 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DAI-003 |
| REQ-AUTO-00437 | SUV2_REQ 121 The integrity check shall be carried out solely by the server.SUV2_REQ 121 The integrity check shall be carried out solely by the server. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 35 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 35 Document section CVS123-2 > Page 35 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DAI-004 |
| REQ-AUTO-00438 | 8.4.1 Request SUV2_REQ 122 The server shall support the routine request according to Table 23.8.4.1 Request SUV2_REQ 122 The server shall support the routine request according to Table 23. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 35 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 35 Document section CVS123-2 > Page 35 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00439 | Page 36 8.4.2 Positive Response SUV2_REQ 123 The server shall support the routine positive re...Page 36 8.4.2 Positive Response SUV2_REQ 123 The server shall support the routine positive response according to Table 24. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 36 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 36 Document section CVS123-2 > Page 36 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00440 | Table 24: Routine 0xFF01 Positive Response Format #1 RoutineControl Response SID M 0x71 #2 ro...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 36 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. | OP-004 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 36 Document section CVS123-2 > Page 36 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-UPD-005 |
| REQ-AUTO-00441 | Table 25: Routine 0xFF01 routineStatus routineResult Format Hex Description Cvt 0x00 correctR...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 36 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 36 Document section CVS123-2 > Page 36 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-DAI-003 |
| REQ-AUTO-00442 | If the server set routineResult as 0x00 (CorrectResult) the server shall reject with NRC 0x24...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: | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 36 | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | Diagnostic security | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 36 Document section CVS123-2 > Page 36 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Diagnostic security | Interface: None | SSR: SSR-RBAC-001 |
| REQ-AUTO-00443 | 8.4.4.3 Parameter routineResultProof SUV2_REQ 171 The server shall hash the receipt number wi...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 37 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 37 Document section CVS123-2 > Page 37 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00444 | SUV2_REQ 172 The hash algorithm shall be SHA512.SUV2_REQ 172 The hash algorithm shall be SHA512. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 37 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 37 Document section CVS123-2 > Page 37 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-004 |
| REQ-AUTO-00445 | SUV2_REQ 173 The server shall sign the hashed output using the receipt-keys.SUV2_REQ 173 The server shall sign the hashed output using the receipt-keys. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 37 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 37 Document section CVS123-2 > Page 37 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00446 | SUV2_REQ 174 The server shall use ED25519 as signature algorithm.SUV2_REQ 174 The server shall use ED25519 as signature algorithm. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 37 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 37 Document section CVS123-2 > Page 37 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DAI-004 |
| REQ-AUTO-00447 | SUV2_REQ 175 The server shall return in the parameter routineResultProof the signed hash.SUV2_REQ 175 The server shall return in the parameter routineResultProof the signed hash. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 37 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 37 Document section CVS123-2 > Page 37 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00448 | Page 38 Figure 5: diagram for signing of software update results 8.4.4.4 Client behaviour aft...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 38 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. | OP-004 | None | OEM/Customer Review Interface | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 38 Document section CVS123-2 > Page 38 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-UPD-003 |
| REQ-AUTO-00449 | SUV2_REQ 176 Once a SDSC has being accepted by the server, the server shall store in the NVM...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 38 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 38 Document section CVS123-2 > Page 38 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00450 | Once a SDSC has being accepted by the server, the server shall accept the following diagnosti...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 | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 38 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | Diagnostic security | None | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 38 Document section CVS123-2 > Page 38 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Diagnostic security | Interface: None | SSR: SSR-RBAC-001 |
| REQ-AUTO-00451 | Page 39 8.5.1 Request SUV2_REQ 129 The server shall support the routine request according to...Page 39 8.5.1 Request SUV2_REQ 129 The server shall support the routine request according to Table 26. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 39 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 39 Document section CVS123-2 > Page 39 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-001 |
| REQ-AUTO-00452 | Table 26: Routine 0xCAFE Request Format Byte Description Cvt Hex #1 RoutineControl Request SI...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 39 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 39 Document section CVS123-2 > Page 39 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00453 | #n EMP Message M 0x00-0xFF 8.5.3 Negative Response SUV2_REQ 131 SUV2_REQ 132 The server shall...#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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 39 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 39 Document section CVS123-2 > Page 39 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00454 | 8.5.4 Routine 0xCAFE Parameters 8.5.4.1 Parameter EMP Message SUV2_REQ 133 The server shall s...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 39 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 39 Document section CVS123-2 > Page 39 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00455 | Page 40 9 Software Verification and Encryption Requirements SUV2_INFO 117 The information req...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). | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 40 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | Secure communication | OEM/Customer Review Interface | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 40 Document section CVS123-2 > Page 40 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Secure communication | Interface: OEM/Customer Review Interface | SSR: SSR-COM-007 |
| REQ-AUTO-00456 | 9.1 General Requirements on SDSC 9.1.1 SDSC Structure SUV2_REQ 134 The server shall implement...9.1 General Requirements on SDSC 9.1.1 SDSC Structure SUV2_REQ 134 The server shall implement SDSC structure as defined in CVS154. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 40 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 40 Document section CVS123-2 > Page 40 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00457 | SUV2_REQ 184 The range start field shall be the memory address offset from the dataLocator fi...SUV2_REQ 184 The range start field shall be the memory address offset from the dataLocator field. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 40 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 40 Document section CVS123-2 > Page 40 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-HW-001 |
| REQ-AUTO-00458 | SUV2_REQ 185 The range length field shall be the number of bytes to be verified.SUV2_REQ 185 The range length field shall be the number of bytes to be verified. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 40 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 40 Document section CVS123-2 > Page 40 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-004 |
| REQ-AUTO-00459 | SUV2_REQ 161 The supplier shall propose for each software module an identification to be used...SUV2_REQ 161 The supplier shall propose for each software module an identification to be used in dataLocator field in SDSC. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 40 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 40 Document section CVS123-2 > Page 40 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-008 |
| REQ-AUTO-00460 | SUV2_REQ 168 The vehicle manufacturer shall review and accept the proposals for every dataLoc...SUV2_REQ 168 The vehicle manufacturer shall review and accept the proposals for every dataLocator. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 40 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 40 Document section CVS123-2 > Page 40 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-009 |
| REQ-AUTO-00461 | The start address shall be used as an offset in the software module while the length can be u...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 40 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 40 Document section CVS123-2 > Page 40 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-008 |
| REQ-AUTO-00462 | 9.1.2 SDSC Sanity Check SUV2_REQ 135 Before accepting the SDSC as valid, the server shall per...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 40 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 40 Document section CVS123-2 > Page 40 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00463 | SUV2_REQ 138 If the sanity check returns fail/invalid, the server shall reject SDSC as descri...SUV2_REQ 138 If the sanity check returns fail/invalid, the server shall reject SDSC as described in CVS34. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 41 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 41 Document section CVS123-2 > Page 41 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00464 | 9.2 Software Verification SUV2_REQ 152 The server shall validate each VerificationEntry found...9.2 Software Verification SUV2_REQ 152 The server shall validate each VerificationEntry found in the SDSC. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 41 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 41 Document section CVS123-2 > Page 41 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-VV-003 |
| REQ-AUTO-00465 | SUV2_REQ 153 Software hashes in the SDSC shall be verified by the server considering the rang...SUV2_REQ 153 Software hashes in the SDSC shall be verified by the server considering the ranges which are stated in the SDSC. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 41 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 41 Document section CVS123-2 > Page 41 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-008 |
| REQ-AUTO-00466 | SUV2_REQ 154 The Ranges dictates the data range that the server shall begin, and end read fro...SUV2_REQ 154 The Ranges dictates the data range that the server shall begin, and end read from NVM for hashing. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 41 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 41 Document section CVS123-2 > Page 41 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00467 | SUV2_INFO 126 The Ranges can be one or several if there are gaps between memory areas which s...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 41 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 41 Document section CVS123-2 > Page 41 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-COM-005 |
| REQ-AUTO-00468 | SUV2_REQ 155 When hashing software, the whole memory range, including erased-only bytes of a...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 41 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 41 Document section CVS123-2 > Page 41 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-008 |
| REQ-AUTO-00469 | Figure 6: Erased-only bytes of a memory module SUV2_REQ 156 The byte value of an erased data...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 41 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | High | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 41 Document section CVS123-2 > Page 41 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-UPD-003 |
| REQ-AUTO-00470 | Page 42 SUV2_REQ 157 The server shall be able to verify that erased-only blocks covered in ra...Page 42 SUV2_REQ 157 The server shall be able to verify that erased-only blocks covered in range of memory are erased. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 42 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 42 Document section CVS123-2 > Page 42 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-HW-001 |
| REQ-AUTO-00471 | SUV2_REQ 158 When the server has verified all verificationEntries, a result OK/NOT_OK shall b...SUV2_REQ 158 When the server has verified all verificationEntries, a result OK/NOT_OK shall be returned. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 42 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 42 Document section CVS123-2 > Page 42 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-VV-002 |
| REQ-AUTO-00472 | SUV2_REQ 159 If NOT_OK is returned, the server shall not accept the new software for execution.SUV2_REQ 159 If NOT_OK is returned, the server shall not accept the new software for execution. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 42 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 42 Document section CVS123-2 > Page 42 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-008 |
| REQ-AUTO-00473 | SUV2_REQ 160 If OK is returned, the server shall accept that installed software is valid in t...SUV2_REQ 160 If OK is returned, the server shall accept that installed software is valid in terms of integrity. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 42 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 42 Document section CVS123-2 > Page 42 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DAI-003 |
| REQ-AUTO-00474 | SUV2_INFO 131 The server may execute other checks to verify the software before concluding if...SUV2_INFO 131 The server may execute other checks to verify the software before concluding if the installed software shall be accepted. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 42 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 42 Document section CVS123-2 > Page 42 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-SYS-008 |
| REQ-AUTO-00475 | 9.3 Software decryption SUV2_REQ 147 For the received data, where a match is found in the Enc...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 42 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 42 Document section CVS123-2 > Page 42 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-008 |
| REQ-AUTO-00476 | SUV2_REQ 148 An initialized data (i.e., cipher scheme) shall be kept active until no more rec...SUV2_REQ 148 An initialized data (i.e., cipher scheme) shall be kept active until no more received data matches the current EncryptionEntry. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 42 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 42 Document section CVS123-2 > Page 42 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-004 |
| REQ-AUTO-00477 | SUV2_REQ 149 The cipher shall be reinitialized for each new Encryption entry.SUV2_REQ 149 The cipher shall be reinitialized for each new Encryption entry. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 42 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 42 Document section CVS123-2 > Page 42 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ-AUTO-00478 | SUV2_REQ 150 According to best practise received data shall be decrypted “on the fly” before...SUV2_REQ 150 According to best practise received data shall be decrypted “on the fly” before storing to NVM. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 42 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 42 Document section CVS123-2 > Page 42 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ-AUTO-00479 | Other methods shall be agreed upon with OEM.Other methods shall be agreed upon with OEM. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 42 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 42 Document section CVS123-2 > Page 42 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ-AUTO-00480 | SUV2_INFO 134 The received data to decrypt may only be parts of a software module and it will...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 42 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 42 Document section CVS123-2 > Page 42 Supplier rationale Source classifies this as Constraint (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00481 | Note that more than one Address field can be specified if there are one or more areas within...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). | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 48 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 48 Document section CVS123-2 > Page 48 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-UPD-002 |
| REQ-AUTO-00482 | S-record Memory layout #00868000 #008AFFFF #00930000 #00BFFFFF #008B0000 #0092FFFF Module has...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 50 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 50 Document section CVS123-2 > Page 50 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-SDT-002 |
| REQ-AUTO-00483 | Module B is encrypted meaning that when the server receives data within a range (given as add...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. | customer-input/pdf/CVS123-2.pdf | CVS123-2 > Page 50 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS123-2.pdf / page 50 Document section CVS123-2 > Page 50 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00484 | The User shall apply the latest version of this CVS124.The User shall apply the latest version of this CVS124. | customer-input/pdf/CVS124.pdf | CVS124 > Page 1 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 1 Document section CVS124 > Page 1 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ-AUTO-00485 | Internal Page 2 (90) Foreword This CVS124 contains requirement specification for TRATON GROUP...Internal Page 2 (90) Foreword This CVS124 contains requirement specification for TRATON GROUP and may be used by all within TRATON Group, if applicable. | customer-input/pdf/CVS124.pdf | CVS124 > Page 2 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 2 Document section CVS124 > Page 2 Supplier rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00486 | Any review of CVS124 shall only be done in agreement with the involved departments stated in...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”. | customer-input/pdf/CVS124.pdf | CVS124 > Page 2 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 2 Document section CVS124 > Page 2 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-009 |
| REQ-AUTO-00487 | • Affiliate means any legal entity that directly or indirectly controls, is controlled by, or...• 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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 2 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 2 Document section CVS124 > Page 2 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00488 | 4 Terms, definitions and abbreviations 4.1 Terms Table 1 – Definition of Terms Term Definitio...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 6 | Needs Customer Clarification | Needs customer clarification. The requirement implies customer-owned infrastructure, approval, or a responsibility split that is not yet available. | Scope and responsibility for each listed requirement. | OP-011 | None | None | Unknown | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 6 Document section CVS124 > Page 6 Supplier rationale Flagged customer_clarification_needed=yes during extraction. Implementation approach Hold implementation; raise an open point and a clarification question. Acceptance condition Customer answers the linked open point. Responsibility assumption OEM / Customer Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00489 | Shall not This phrase, or the phrase "Must not", means that the definition is an absolute pro...Shall not This phrase, or the phrase "Must not", means that the definition is an absolute prohibition of the specification. | customer-input/pdf/CVS124.pdf | CVS124 > Page 6 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 6 Document section CVS124 > Page 6 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ-AUTO-00490 | Should This word, or the adjective “Recommended”, means that there may exist valid reasons in...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 6 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 6 Document section CVS124 > Page 6 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ-AUTO-00491 | Should not This phrase, or the phrase “Not recommended”, means that there may exist valid rea...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 6 | Needs Internal Review | Needs internal review. Confirm whether this should-level requirement is in the committed baseline. | No customer action until supplier review is complete. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 6 Document section CVS124 > Page 6 Supplier rationale Non-mandatory wording; baseline inclusion not yet confirmed. Implementation approach Decide baseline inclusion internally, then issue an Accept/Partial position. Acceptance condition Internal baseline decision recorded. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00492 | May This word, or the adjective “Optional”, means that an item is truly optional.May This word, or the adjective “Optional”, means that an item is truly optional. | customer-input/pdf/CVS124.pdf | CVS124 > Page 6 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 6 Document section CVS124 > Page 6 Supplier rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00493 | One vendor may choose to include the item because a particular marketplace requires it or bec...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 6 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 6 Document section CVS124 > Page 6 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00494 | An implementation which does not include a particular option shall be prepared to interoperat...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 6 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 6 Document section CVS124 > Page 6 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ-AUTO-00495 | In the same vein an implementation which does include a particular option shall be prepared t...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). | customer-input/pdf/CVS124.pdf | CVS124 > Page 6 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 6 Document section CVS124 > Page 6 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ-AUTO-00496 | Internal Page 7 (90) ISO International Organization for Standardization non-Def Non-default d...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 7 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | Diagnostic security | OEM/Customer Review Interface | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 7 Document section CVS124 > Page 7 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Diagnostic security | Interface: OEM/Customer Review Interface | SSR: SSR-RBAC-001 |
| REQ-AUTO-00497 | If valid data is not needed for the use-case and system at hand, default values should be used.If valid data is not needed for the use-case and system at hand, default values should be used. | customer-input/pdf/CVS124.pdf | CVS124 > Page 7 | Needs Internal Review | Needs internal review. Confirm whether this should-level requirement is in the committed baseline. | No customer action until supplier review is complete. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 7 Document section CVS124 > Page 7 Supplier rationale Non-mandatory wording; baseline inclusion not yet confirmed. Implementation approach Decide baseline inclusion internally, then issue an Accept/Partial position. Acceptance condition Internal baseline decision recorded. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00498 | E Mandatory for ECUs which shall be compliant with OBD legislation Worldwide like ISO27145,J1...E Mandatory for ECUs which shall be compliant with OBD legislation Worldwide like ISO27145,J1979 etc C Conditional U User optional. | customer-input/pdf/CVS124.pdf | CVS124 > Page 7 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 7 Document section CVS124 > Page 7 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ-AUTO-00499 | Shall be agreed between the supplier and the vehicle manufacturer.Shall be agreed between the supplier and the vehicle manufacturer. | customer-input/pdf/CVS124.pdf | CVS124 > Page 7 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 7 Document section CVS124 > Page 7 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-005 |
| REQ_UDS-0001 | Internal Page 8 (90) 5 Requirements 5.1 General Requirements REQ_UDS 0001 The implementation...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 8 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 8 Document section CVS124 > Page 8 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DIAG-003 |
| REQ_UDS-0002 | REQ_UDS 0002 All deviations and extensions shall be agreed with the applicable vehicle manufa...REQ_UDS 0002 All deviations and extensions shall be agreed with the applicable vehicle manufacturer and shall be documented. | customer-input/pdf/CVS124.pdf | CVS124 > Page 8 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 8 Document section CVS124 > Page 8 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-DIAG-001 |
| REQ_UDS-0003 | Modified requirements: REQ_UDS 0003: Added semantic Identifier DIDs, changed the NodeUID DID...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 | customer-input/pdf/CVS124.pdf | CVS124 > Page 8 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 8 Document section CVS124 > Page 8 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0004 | Internal Page 10 (90) 5.2.1.1 DID 0xF180 bootSoftwareIdentificationDataIdentifier REQ_UDS 000...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 . | customer-input/pdf/CVS124.pdf | CVS124 > Page 10 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 10 Document section CVS124 > Page 10 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0005 | 0x20 REQ_UDS 0005 This DID shall be stored under flash memory module in flash memory.0x20 REQ_UDS 0005 This DID shall be stored under flash memory module in flash memory. | customer-input/pdf/CVS124.pdf | CVS124 > Page 10 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 10 Document section CVS124 > Page 10 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-UPD-002 |
| REQ_UDS-0006 | 5.2.1.2 DID 0xF181 applicationSoftwareIdentificationDataIdentifier REQ_UDS 0006 Table 7 – Des...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 | customer-input/pdf/CVS124.pdf | CVS124 > Page 10 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 10 Document section CVS124 > Page 10 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0007 | Internal Page 11 (90) REQ_UDS 0231 5.2.1.3 DID 0xF182 applicationDataIdentificationDataIdenti...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 . | customer-input/pdf/CVS124.pdf | CVS124 > Page 11 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 11 Document section CVS124 > Page 11 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0232 | 0x7E 0x20 REQ_UDS 0232 This DID shall be stored under dataset module stored in flash memory.0x7E 0x20 REQ_UDS 0232 This DID shall be stored under dataset module stored in flash memory. | customer-input/pdf/CVS124.pdf | CVS124 > Page 11 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 11 Document section CVS124 > Page 11 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-UPD-002 |
| REQ_UDS-0008 | 5.2.1.4 DID 0xF186 ActiveDiagnosticSessionDataIdentifier REQ_UDS 0008 Table 9 – Description o...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 | customer-input/pdf/CVS124.pdf | CVS124 > Page 11 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 11 Document section CVS124 > Page 11 Supplier rationale Source classifies this as Cybersecurity control (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0009 | Internal Page 12 (90) 5.2.1.5 DID 0xF187 vehicleManufacturerSparePartNumberDataIdentifier REQ...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 12 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 12 Document section CVS124 > Page 12 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-UPD-002 |
| REQ_UDS-0010 | 5.2.1.6 DID 0xF188 vehicleManufacturerECUSoftwareNumberDataIdentifier REQ_UDS 0010 Table 11 –...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 | customer-input/pdf/CVS124.pdf | CVS124 > Page 12 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 12 Document section CVS124 > Page 12 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0012 | Byte #7 Correction Byte #8 Correction Byte #9 Correction Byte #10 Correction XX.YY.ZZZZ (XX –...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 . | customer-input/pdf/CVS124.pdf | CVS124 > Page 13 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 13 Document section CVS124 > Page 13 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-DIAG-001 |
| 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,...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 14 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 14 Document section CVS124 > Page 14 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00513 | Minimum length shall be 8 bytes and the assigned value shall be unique for every unit provide...Minimum length shall be 8 bytes and the assigned value shall be unique for every unit provided by one supplier per project. | customer-input/pdf/CVS124.pdf | CVS124 > Page 14 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 14 Document section CVS124 > Page 14 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-005 |
| REQ_UDS-0015 | 5.2.1.11 DID 0xF190 VINDataIdentifier REQ_UDS 0015 Table 16 – Description of DID 0xF190 VINDa...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 . | customer-input/pdf/CVS124.pdf | CVS124 > Page 14 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 14 Document section CVS124 > Page 14 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0016 | 5.2.1.12 DID 0xF191 vehicleManufacturerECUHardwareNumberDataIdentifier REQ_UDS 0016 Table 17...5.2.1.12 DID 0xF191 vehicleManufacturerECUHardwareNumberDataIdentifier REQ_UDS 0016 Table 17 – Description of DID 0xF191 vehicleManufacturerECUHardwareNumberDataIdentifier 0xF191 Name: vehicleManufacturerECUHardwareNumberDataIdentifier Byte Data | customer-input/pdf/CVS124.pdf | CVS124 > Page 14 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 14 Document section CVS124 > Page 14 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0236 | 0x20 REQ_UDS 0236 This DID shall be stored under flash memory module in flash memory.0x20 REQ_UDS 0236 This DID shall be stored under flash memory module in flash memory. | customer-input/pdf/CVS124.pdf | CVS124 > Page 15 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 15 Document section CVS124 > Page 15 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-UPD-002 |
| REQ_UDS-0017 | 5.2.1.13 DID 0xF192 systemSupplierECUHardwareNumberDataIdentifier REQ_UDS 0017 Table 18 – Des...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 | customer-input/pdf/CVS124.pdf | CVS124 > Page 15 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 15 Document section CVS124 > Page 15 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0020 | Internal Page 16 (90) 5.2.1.16 DID 0xF195 systemSupplierECUSoftwareVersionNumberDataIdentifie...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 . | customer-input/pdf/CVS124.pdf | CVS124 > Page 16 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 16 Document section CVS124 > Page 16 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0237 | 0x20 REQ_UDS 0237 INFO_UDS 0039 The format should follow the pattern: Appl: <Diag.family> <Di...0x20 REQ_UDS 0237 INFO_UDS 0039 The format should follow the pattern: Appl: <Diag.family> <Diag.generation> Boot: <Diag.family> <Diag.generation>_BOOT | customer-input/pdf/CVS124.pdf | CVS124 > Page 16 | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm or correct the stated supplier assumption. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 16 Document section CVS124 > Page 16 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0339 | Internal Page 90 (90) Annex C (informative) Change history Release date Changes 2025-12 New r...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 17 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 17 Document section CVS124 > Page 17 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0340 | 5.2.1.20 DID 0xF199 SoftwareAssemblySemanticDataIdentifiers REQ_UDS 0340 Table 25 – Descripti...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 | customer-input/pdf/CVS124.pdf | CVS124 > Page 17 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 17 Document section CVS124 > Page 17 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0341 | 5.2.1.21 DID 0xF19A HardwareSemanticDataIdentifiers REQ_UDS 0341 Table 26 – Description of DI...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 18 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 18 Document section CVS124 > Page 18 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0023 | Internal Page 19 (90) 5.2.1.22 DID 0xF19D ECUInstallationDateDataIdentifier REQ_UDS 0023 Tabl...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 . | customer-input/pdf/CVS124.pdf | CVS124 > Page 19 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 19 Document section CVS124 > Page 19 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0025 | #8 Format: “YYYYMMDD” byte #1 YY (most significant) byte #2 YY byte #3 YY byte #4 YY byte #5...#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 | customer-input/pdf/CVS124.pdf | CVS124 > Page 19 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 19 Document section CVS124 > Page 19 Supplier rationale Source classifies this as Constraint (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0027 | Internal Page 20 (90) 5.2.1.25 DID 0xF1A9 Lifetime ECU-runtime at software update stamp REQ_U...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 20 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 20 Document section CVS124 > Page 20 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-UPD-003 |
| REQ_UDS-0028 | REQ_UDS 0028 Table 30 – Description of DID 0xF1A9 Lifetime ECU-runtime at software update sta...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 20 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 20 Document section CVS124 > Page 20 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-UPD-003 |
| REQ_UDS-0030 | REQ_UDS 0030 Table 31 – Description of DID 0xF1AA Mileage at software update stamp ID Descrip...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 20 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 20 Document section CVS124 > Page 20 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0032 | Internal Page 21 (90) REQ_UDS 0032 Table 32 – Description of DID 0xF1AB Date at software upda...Internal Page 21 (90) REQ_UDS 0032 Table 32 – Description of DID 0xF1AB Date at software update stamp 0xF1AB Name: dateAtSoftwareUpdateStamp Byte Data #1 . | customer-input/pdf/CVS124.pdf | CVS124 > Page 21 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 21 Document section CVS124 > Page 21 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0033 | 5.2.1.28 DID 0xF1AD activeECUSoftwareDataIdentifier REQ_UDS 0033 Table 33 – Description of DI...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 | customer-input/pdf/CVS124.pdf | CVS124 > Page 21 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 21 Document section CVS124 > Page 21 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0036 | 5.2.1.30 DID 0xF1B9 RBACCIdentifierNumber REQ_UDS 0036 Table 35 – Description of DID 0xF1B9 R...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 22 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 22 Document section CVS124 > Page 22 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0037 | 5.2.1.31 DID 0xF1BA RBACCStructureVersion REQ_UDS 0037 Table 36 – Description of DID 0xF1BA R...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 22 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 22 Document section CVS124 > Page 22 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0038 | 5.2.1.32 DID 0xF1D1 RootCertificateIdentifier REQ_UDS 0038 Table 37 – Description of DID 0xF1...5.2.1.32 DID 0xF1D1 RootCertificateIdentifier REQ_UDS 0038 Table 37 – Description of DID 0xF1D1 RootCertificateIdentifier 0xF1D1 Name: RootCertificateIdentifier Byte Data | customer-input/pdf/CVS124.pdf | CVS124 > Page 22 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 22 Document section CVS124 > Page 22 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0039 | 32-Bytes A_BYTEFIEL D M : M 0x00 – 0xFF 0x20 5.2.1.33 DID 0xF1E1 vehicleManufacturerECUBootSo...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 23 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 23 Document section CVS124 > Page 23 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-UPD-002 |
| REQ_UDS-0040 | 5.3 Diagnostic sessions requirements REQ_UDS 0040 A default diagnostic session shall be suppo...5.3 Diagnostic sessions requirements REQ_UDS 0040 A default diagnostic session shall be supported. | customer-input/pdf/CVS124.pdf | CVS124 > Page 23 | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm or correct the stated supplier assumption. | - | Diagnostic security | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 23 Document section CVS124 > Page 23 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Diagnostic security | Interface: None | SSR: SSR-RBAC-001 |
| REQ_UDS-0041 | REQ_UDS 0041 The default diagnostic session is referred to as “defaultSession”.REQ_UDS 0041 The default diagnostic session is referred to as “defaultSession”. | customer-input/pdf/CVS124.pdf | CVS124 > Page 23 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 23 Document section CVS124 > Page 23 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0042 | REQ_UDS 0042 A non-default diagnostic session referred to as “extendedDiagnosticSession” shal...REQ_UDS 0042 A non-default diagnostic session referred to as “extendedDiagnosticSession” shall be supported. | customer-input/pdf/CVS124.pdf | CVS124 > Page 23 | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm or correct the stated supplier assumption. | - | Diagnostic security | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 23 Document section CVS124 > Page 23 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Diagnostic security | Interface: None | SSR: SSR-RBAC-001 |
| REQ_UDS-0043 | REQ_UDS 0043 Diagnostic sessions not defined in this document shall be agreed with the vehicl...REQ_UDS 0043 Diagnostic sessions not defined in this document shall be agreed with the vehicle manufacturer. | customer-input/pdf/CVS124.pdf | CVS124 > Page 23 | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm or correct the stated supplier assumption. | - | Diagnostic security | OEM/Customer Review Interface | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 23 Document section CVS124 > Page 23 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Diagnostic security | Interface: OEM/Customer Review Interface | SSR: SSR-RBAC-001 |
| REQ_UDS-0044 | REQ_UDS 0044 Of a marked service, an execution shall be implemented for the specified session...REQ_UDS 0044 Of a marked service, an execution shall be implemented for the specified session as perTable 39. | customer-input/pdf/CVS124.pdf | CVS124 > Page 23 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 23 Document section CVS124 > Page 23 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ_UDS-0045 | Internal Page 24 (90) REQ_UDS 0045 Table 39 – Diagnostic service support Service according to...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 24 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 24 Document section CVS124 > Page 24 Supplier rationale Source classifies this as Cybersecurity control (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00540 | Internal Page 25 (90) INFO_UDS 0038 In Table 39, bootloader sessions should only be applicabl...Internal Page 25 (90) INFO_UDS 0038 In Table 39, bootloader sessions should only be applicable to Software updateable ECUs. | customer-input/pdf/CVS124.pdf | CVS124 > Page 25 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 25 Document section CVS124 > Page 25 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-BOOT-001 |
| REQ_UDS-0046 | REQ_UDS 0046 The mapping of RoutineControl service routines to sessions shall be discussed an...REQ_UDS 0046 The mapping of RoutineControl service routines to sessions shall be discussed and agreed with the vehicle manufacturer. | customer-input/pdf/CVS124.pdf | CVS124 > Page 25 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 25 Document section CVS124 > Page 25 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-DIAG-004 |
| REQ_UDS-0047 | REQ_UDS 0047 The server shall implement support for RBAC (Role Based Access Control) based on...REQ_UDS 0047 The server shall implement support for RBAC (Role Based Access Control) based on CVS151. | customer-input/pdf/CVS124.pdf | CVS124 > Page 25 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 25 Document section CVS124 > Page 25 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ_UDS-0048 | REQ_UDS 0048 CVS31 and CVS32 requirements preconditions per service shall be defined by the R...REQ_UDS 0048 CVS31 and CVS32 requirements preconditions per service shall be defined by the RBAC Configuration file in the ECU. | customer-input/pdf/CVS124.pdf | CVS124 > Page 25 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 25 Document section CVS124 > Page 25 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-RBAC-004 |
| REQ_UDS-0049 | REQ_UDS 0049 Diagnostics safe state is the following conditions that needs be satisfied to en...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 25 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 25 Document section CVS124 > Page 25 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0050 | The conditions that shall be checked are • Vehicle speed ~ 0 • Engine speed ~ 0 (for vehicles...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 25 | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 25 Document section CVS124 > Page 25 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0051 | Internal Page 26 (90) Diagnostics Service Diag Safe state check Application Boot loader Trans...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). | customer-input/pdf/CVS124.pdf | CVS124 > Page 26 | Needs Customer Clarification | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 26 Document section CVS124 > Page 26 Supplier rationale Flagged customer_clarification_needed=yes during extraction. Implementation approach Hold implementation; raise an open point and a clarification question. Acceptance condition Customer answers the linked open point. Responsibility assumption OEM / Customer Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0338 | Internal Page 27 (90) Figure 2 -State Diagram REQ_UDS 0338 The session transitions stated bel...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 27 | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 27 Document section CVS124 > Page 27 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DIAG-003 |
| REQ_UDS-0305 | INFO_UDS 0019 Description of the individual transitions as per Figure 2 -State Diagram is exp...INFO_UDS 0019 Description of the individual transitions as per Figure 2 -State Diagram is explained from REQ_UDS 0305 to REQ_UDS 0337. | customer-input/pdf/CVS124.pdf | CVS124 > Page 27 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 27 Document section CVS124 > Page 27 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0306 | Internal Page 28 (90) REQ_UDS 0306 2.Internal Page 28 (90) REQ_UDS 0306 2. | customer-input/pdf/CVS124.pdf | CVS124 > Page 28 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 28 Document section CVS124 > Page 28 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0316 | Internal Page 29 (90) REQ_UDS 0316 12.Internal Page 29 (90) REQ_UDS 0316 12. | customer-input/pdf/CVS124.pdf | CVS124 > Page 29 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 29 Document section CVS124 > Page 29 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0328 | Internal Page 30 (90) REQ_UDS 0328 24.Internal Page 30 (90) REQ_UDS 0328 24. | customer-input/pdf/CVS124.pdf | CVS124 > Page 30 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 30 Document section CVS124 > Page 30 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0052 | Internal Page 31 (90) 5.4 Data identifier requirements REQ_UDS 0052 Project specific DID shal...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 31 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 31 Document section CVS124 > Page 31 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-DIAG-005 |
| REQ_UDS-0053 | REQ_UDS 0053 Table 41 lists reserved ECU DIDs/DID ranges which are not used for identificatio...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 31 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 31 Document section CVS124 > Page 31 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-DIAG-006 |
| REQ_UDS-0054 | REQ_UDS 0054 These ECUs shall implement the following DIDs according to Table 42.REQ_UDS 0054 These ECUs shall implement the following DIDs according to Table 42. | customer-input/pdf/CVS124.pdf | CVS124 > Page 31 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 31 Document section CVS124 > Page 31 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0055 | Internal Page 32 (90) 5.5 Diagnostic services requirements REQ_UDS 0055 The SPRMIB shall be s...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). | customer-input/pdf/CVS124.pdf | CVS124 > Page 32 | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm or correct the stated supplier assumption. | - | Diagnostic security | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 32 Document section CVS124 > Page 32 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Diagnostic security | Interface: None | SSR: SSR-RBAC-001 |
| REQ_UDS-0056 | REQ_UDS 0056 Negative response codes specified in ISO 14229-1 Annex A.1 shall only be support...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 32 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 32 Document section CVS124 > Page 32 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-005 |
| REQ_UDS-0342 | REQ_UDS 0342 Negative response code 0x22, conditionsNotCorrect , shall be used if a service r...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 32 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 32 Document section CVS124 > Page 32 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-RBAC-004 |
| REQ_UDS-0057 | 5.5.1 DiagnosticSessionControl (0x10) service 5.5.1.1 Request REQ_UDS 0239 5.5.1.1.1 Request...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 32 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 32 Document section CVS124 > Page 32 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-UPD-003 |
| REQ-AUTO-00559 | The application shall respond with NRC 0x22 (conditionsNotCorrect) if communication has not b...The application shall respond with NRC 0x22 (conditionsNotCorrect) if communication has not been switched off. | customer-input/pdf/CVS124.pdf | CVS124 > Page 32 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 32 Document section CVS124 > Page 32 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ_UDS-0058 | REQ_UDS 0058 Table 43 – Service 0x10 request parameter diagnosticSessionType description Hex...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 32 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 32 Document section CVS124 > Page 32 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-UPD-003 |
| REQ-AUTO-00561 | In this process, it shall end all routines and functions that influence programming and ensur...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 32 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. | OP-004 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 32 Document section CVS124 > Page 32 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-UPD-005 |
| REQ_UDS-0060 | REQ_UDS 0060 Before switching to programming session, the server shall ensure the applicable...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 32 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 32 Document section CVS124 > Page 32 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-UPD-005 |
| REQ-AUTO-00563 | Its upto the ECU to include the conditions that are relevant for that particular ECU, but nee...Its upto the ECU to include the conditions that are relevant for that particular ECU, but needs to be agreed with Vehicle Manufacturer. | customer-input/pdf/CVS124.pdf | CVS124 > Page 32 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 32 Document section CVS124 > Page 32 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0061 | Internal Page 33 (90) 5.5.1.2 Positive response REQ_UDS 0240 REQ_UDS 0061 Positive response s...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 33 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 33 Document section CVS124 > Page 33 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-UPD-001 |
| REQ_UDS-0241 | 5.5.1.2.1 Response parameter diagnosticSessionType REQ_UDS 0241 Response parameter diagnostic...5.5.1.2.1 Response parameter diagnosticSessionType REQ_UDS 0241 Response parameter diagnosticSessionType shall be as per ISO 14229-1. | customer-input/pdf/CVS124.pdf | CVS124 > Page 33 | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 33 Document section CVS124 > Page 33 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-005 |
| REQ_UDS-0242 | 5.5.1.2.2 Response parameter sessionParameterRecord REQ_UDS 0242 Response parameter sessionPa...5.5.1.2.2 Response parameter sessionParameterRecord REQ_UDS 0242 Response parameter sessionParameterRecord shall be as per ISO 14229-1. | customer-input/pdf/CVS124.pdf | CVS124 > Page 33 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 33 Document section CVS124 > Page 33 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-005 |
| REQ_UDS-0062 | 5.5.1.3 Negative response REQ_UDS 0243 5.5.2 ECUReset (0x11) service REQ_UDS 0062 An ECUReset...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 33 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 33 Document section CVS124 > Page 33 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ_UDS-0063 | REQ_UDS 0063 ECU shall execute the reset only after sending a positive response to the ECU re...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 33 | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | Diagnostic security | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 33 Document section CVS124 > Page 33 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Diagnostic security | Interface: None | SSR: SSR-RBAC-001 |
| REQ_UDS-0065 | REQ_UDS 0065 The server shall be available for ECU identification within one second after sen...REQ_UDS 0065 The server shall be available for ECU identification within one second after sending positive response message to an ECUReset request. | customer-input/pdf/CVS124.pdf | CVS124 > Page 33 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 33 Document section CVS124 > Page 33 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DIAG-006 |
| REQ_UDS-0066 | REQ_UDS 0066 After ECU reset, ECU shall be restarted and re-initialized within 2sec.REQ_UDS 0066 After ECU reset, ECU shall be restarted and re-initialized within 2sec. | customer-input/pdf/CVS124.pdf | CVS124 > Page 33 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 33 Document section CVS124 > Page 33 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-006 |
| REQ_UDS-0067 | REQ_UDS 0067 The maximum time it takes from the positive response is sent from the server unt...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 33 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 33 Document section CVS124 > Page 33 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-DIAG-003 |
| REQ_UDS-0068 | Internal Page 34 (90) 5.5.2.1 Request REQ_UDS 0244 5.5.2.1.1 Request parameter resetType REQ_...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 34 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | Key management | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 34 Document section CVS124 > Page 34 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Key management | Interface: None | SSR: SSR-KEY-001 |
| REQ-AUTO-00573 | the disconnect from the battery shall not be simulated.the disconnect from the battery shall not be simulated. | customer-input/pdf/CVS124.pdf | CVS124 > Page 34 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 34 Document section CVS124 > Page 34 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ-AUTO-00574 | The implementation of hardReset shall first ensure that data corruption will not occur.The implementation of hardReset shall first ensure that data corruption will not occur. | customer-input/pdf/CVS124.pdf | CVS124 > Page 34 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 34 Document section CVS124 > Page 34 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ_UDS-0070 | REQ_UDS 0070 The ECUReset service with requestParameter value 0x02 (keyOffOnReset) shall simu...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 34 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | Key management | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 34 Document section CVS124 > Page 34 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Key management | Interface: None | SSR: SSR-KEY-001 |
| REQ_UDS-0071 | REQ_UDS 0071 The implementation of ECUReset service with requestParameter value 0x02 (keyOffO...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 34 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 34 Document section CVS124 > Page 34 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ_UDS-0072 | REQ_UDS 0072 The implementation of ECUReset service with requestParameter value 0x02 (keyOffO...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 34 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 34 Document section CVS124 > Page 34 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ-AUTO-00578 | INFO_UDS 0010 The server shall send an ECUReset positive response message after the server ta...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 34 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 34 Document section CVS124 > Page 34 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DIAG-003 |
| REQ_UDS-0073 | 5.5.2.2 Positive response REQ_UDS 0073 Table 45 – Service 0x11 positive response parameter de...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 | customer-input/pdf/CVS124.pdf | CVS124 > Page 34 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 34 Document section CVS124 > Page 34 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0245 | Internal Page 35 (90) 5.5.2.2.1 Response parameter resetType REQ_UDS 0245 Response parameter...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 35 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 35 Document section CVS124 > Page 35 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-005 |
| REQ_UDS-0074 | 5.5.2.3 Negative response REQ_UDS 0246 5.5.2.3.1 Supported negative response codes REQ_UDS 00...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 35 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 35 Document section CVS124 > Page 35 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0075 | 5.5.3 CommunicationControl (0x28) service REQ_UDS 0075 Servers involved in engine start shall...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 35 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 35 Document section CVS124 > Page 35 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ-AUTO-00583 | If a request is received before this time has passed the server shall respond with NRC 0x78 (...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). | customer-input/pdf/CVS124.pdf | CVS124 > Page 35 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 35 Document section CVS124 > Page 35 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-003 |
| REQ_UDS-0076 | INFO_UDS 0011 This requirement mitigates DOS (Denial Of Service) attacks REQ_UDS 0076 When re...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 35 | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | Diagnostic security | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 35 Document section CVS124 > Page 35 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Diagnostic security | Interface: None | SSR: SSR-RBAC-001 |
| REQ-AUTO-00585 | INFO_UDS 0013 Communication control service should not only be used to improve the bandwidth...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 36 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 36 Document section CVS124 > Page 36 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-UPD-003 |
| REQ_UDS-0078 | 5.5.3.1 Request REQ_UDS 0078 Table 47 – Service 0x28 request parameter description 1 Communic...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 | customer-input/pdf/CVS124.pdf | CVS124 > Page 36 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 36 Document section CVS124 > Page 36 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0081 | Internal Page 37 (90) 5.5.4 TesterPresent (0x3E) service 5.5.4.1 General service requirements...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 37 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 37 Document section CVS124 > Page 37 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ-AUTO-00588 | INFO_UDS 0014 A functionally addressed TesterPresent may arrive at any time during another re...INFO_UDS 0014 A functionally addressed TesterPresent may arrive at any time during another request. | customer-input/pdf/CVS124.pdf | CVS124 > Page 37 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 37 Document section CVS124 > Page 37 Supplier rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0249 | 5.5.4.2 Request REQ_UDS 0249 Request format and parameter shall be as per ISO 14229-1.5.5.4.2 Request REQ_UDS 0249 Request format and parameter shall be as per ISO 14229-1. | customer-input/pdf/CVS124.pdf | CVS124 > Page 37 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 37 Document section CVS124 > Page 37 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-005 |
| REQ_UDS-0250 | 5.5.4.3 Positive response REQ_UDS 0250 5.5.4.4 Negative response REQ_UDS 0251 5.5.5 ControlDT...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 37 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 37 Document section CVS124 > Page 37 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-UPD-003 |
| REQ_UDS-0344 | REQ_UDS 0344 The execution of this service in the application shall only impact the DTC setti...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). | customer-input/pdf/CVS124.pdf | CVS124 > Page 37 | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm or correct the stated supplier assumption. | - | Diagnostic security | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 37 Document section CVS124 > Page 37 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Diagnostic security | Interface: None | SSR: SSR-RBAC-001 |
| REQ_UDS-0345 | 5.5.5.1 Request REQ_UDS 0345 Refer to ISO 14229-1 for request format.5.5.5.1 Request REQ_UDS 0345 Refer to ISO 14229-1 for request format. | customer-input/pdf/CVS124.pdf | CVS124 > Page 37 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 37 Document section CVS124 > Page 37 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0346 | 5.5.5.1.1 Request parameter DTCSettingType REQ_UDS 0346 Refer to ISO 14229-1 for request para...5.5.5.1.1 Request parameter DTCSettingType REQ_UDS 0346 Refer to ISO 14229-1 for request parameter DTCSettingType. | customer-input/pdf/CVS124.pdf | CVS124 > Page 37 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 37 Document section CVS124 > Page 37 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0347 | Internal Page 38 (90) 5.5.5.1.2 Request parameter DTCSettingControlOptionRecord REQ_UDS 0347...Internal Page 38 (90) 5.5.5.1.2 Request parameter DTCSettingControlOptionRecord REQ_UDS 0347 Refer to ISO 14229-1 for request parameter DTCSettingControlOptionRecord. | customer-input/pdf/CVS124.pdf | CVS124 > Page 38 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 38 Document section CVS124 > Page 38 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0348 | 5.5.5.2 Positive response REQ_UDS 0348 Refer to ISO 14229-1 for positive response format and...5.5.5.2 Positive response REQ_UDS 0348 Refer to ISO 14229-1 for positive response format and parameter. | customer-input/pdf/CVS124.pdf | CVS124 > Page 38 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 38 Document section CVS124 > Page 38 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0349 | 5.5.5.3 Negative response REQ_UDS 0349 Refer to ISO 14229-1 for negative response format and...5.5.5.3 Negative response REQ_UDS 0349 Refer to ISO 14229-1 for negative response format and codes. | customer-input/pdf/CVS124.pdf | CVS124 > Page 38 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 38 Document section CVS124 > Page 38 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0082 | 5.5.6 Link Control (0x87) service REQ_UDS 0082 The server shall be able to switch baud rate w...5.5.6 Link Control (0x87) service REQ_UDS 0082 The server shall be able to switch baud rate within one second. | customer-input/pdf/CVS124.pdf | CVS124 > Page 38 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 38 Document section CVS124 > Page 38 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ_UDS-0083 | REQ_UDS 0083 The boot loader shall inherit the selected baud rate if the LinkControl service...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 38 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 38 Document section CVS124 > Page 38 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-BOOT-001 |
| REQ_UDS-0084 | REQ_UDS 0084 Positive response shall be sent before the actual switch of the baud-rate takes...REQ_UDS 0084 Positive response shall be sent before the actual switch of the baud-rate takes place. | customer-input/pdf/CVS124.pdf | CVS124 > Page 38 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 38 Document section CVS124 > Page 38 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0085 | Internal Page 39 (90) 5.5.6.1 Request 5.5.6.2 Request parameter linkControlType REQ_UDS 0085...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 39 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 39 Document section CVS124 > Page 39 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ_UDS-0087 | 5.5.6.3 Positive response REQ_UDS 0252 5.5.6.4 Negative Response REQ_UDS 0253 5.5.7 ReadDataB...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). | customer-input/pdf/CVS124.pdf | CVS124 > Page 39 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 39 Document section CVS124 > Page 39 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ_UDS-0255 | 5.5.7.1.1 Request parameter dataIdentifier REQ_UDS 0255 DataIdentifier parameter definition s...5.5.7.1.1 Request parameter dataIdentifier REQ_UDS 0255 DataIdentifier parameter definition shall be as per ISO 14229-1. | customer-input/pdf/CVS124.pdf | CVS124 > Page 39 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 39 Document section CVS124 > Page 39 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-005 |
| REQ_UDS-0088 | Internal Page 40 (90) REQ_UDS 0088 The data identifier ranges specified in Table 41 shall be...Internal Page 40 (90) REQ_UDS 0088 The data identifier ranges specified in Table 41 shall be followed. | customer-input/pdf/CVS124.pdf | CVS124 > Page 40 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 40 Document section CVS124 > Page 40 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0089 | 5.5.7.2 Positive response REQ_UDS 0256 5.5.7.3 Negative response REQ_UDS 0257 5.5.8 WriteData...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 40 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 40 Document section CVS124 > Page 40 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ_UDS-0091 | REQ_UDS 0091 All changed data shall be valid and stored into non-volatile memory at the lates...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 40 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 40 Document section CVS124 > Page 40 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-006 |
| REQ_UDS-0092 | REQ_UDS 0092 If it is necessary to force an explicit transfer of buffered data into non-volat...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). | customer-input/pdf/CVS124.pdf | CVS124 > Page 40 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | Key management | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 40 Document section CVS124 > Page 40 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Key management | Interface: None | SSR: SSR-KEY-001 |
| REQ_UDS-0093 | REQ_UDS 0093 Additional client requests which start copying RAM buffer data into non-volatile...REQ_UDS 0093 Additional client requests which start copying RAM buffer data into non-volatile memory are not allowed. | customer-input/pdf/CVS124.pdf | CVS124 > Page 40 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 40 Document section CVS124 > Page 40 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00608 | If this action is necessary then it shall be integrated implicitly into ECU Reset (0x11) Serv...If this action is necessary then it shall be integrated implicitly into ECU Reset (0x11) Service subfunction 0x02. | customer-input/pdf/CVS124.pdf | CVS124 > Page 40 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 40 Document section CVS124 > Page 40 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-008 |
| REQ_UDS-0258 | 5.5.8.1 Request REQ_UDS 0258 Request format and parameter shall be as per ISO 14229-1.5.5.8.1 Request REQ_UDS 0258 Request format and parameter shall be as per ISO 14229-1. | customer-input/pdf/CVS124.pdf | CVS124 > Page 40 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 40 Document section CVS124 > Page 40 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-005 |
| REQ_UDS-0259 | 5.5.8.2 Positive response REQ_UDS 02595.5.8.2 Positive response REQ_UDS 0259 | customer-input/pdf/CVS124.pdf | CVS124 > Page 40 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 40 Document section CVS124 > Page 40 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0260 | Internal Page 41 (90) 5.5.8.3 Negative response REQ_UDS 0260 5.5.9 ClearDiagnosticInformation...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 41 | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 41 Document section CVS124 > Page 41 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ_UDS-0094 | 5.5.9.2 Positive response REQ_UDS 0263 5.5.9.3 Negative response REQ_UDS 0264 5.5.10 ReadDTCI...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 | customer-input/pdf/CVS124.pdf | CVS124 > Page 41 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 41 Document section CVS124 > Page 41 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0095 | Internal Page 42 (90) 0x10 reportMirrorMemoryDTCExtendedDataRecordByDTCNumber U 0x11 reportNu...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 42 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 42 Document section CVS124 > Page 42 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0266 | 5.5.10.1.2 Request parameter reportNumberOfDTCByStatusMask REQ_UDS 0266 ReportNumberOfDTCBySt...5.5.10.1.2 Request parameter reportNumberOfDTCByStatusMask REQ_UDS 0266 ReportNumberOfDTCByStatusMask parameter format shall be as per ISO 14229-1. | customer-input/pdf/CVS124.pdf | CVS124 > Page 42 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 42 Document section CVS124 > Page 42 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-005 |
| REQ_UDS-0267 | 5.5.10.1.3 Request parameter DTCStatusMask REQ_UDS 0267 DTCStatusMask parameter format shall...5.5.10.1.3 Request parameter DTCStatusMask REQ_UDS 0267 DTCStatusMask parameter format shall be as per ISO 14229-1. | customer-input/pdf/CVS124.pdf | CVS124 > Page 42 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 42 Document section CVS124 > Page 42 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-005 |
| REQ_UDS-0096 | 5.5.10.1.4 Request parameter DTCMaskRecord REQ_UDS 0096 Table 53 – Service 0x19 request param...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 42 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 42 Document section CVS124 > Page 42 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ_UDS-0268 | 5.5.10.1.5 Request parameter DTCSnapshotRecordNumber REQ_UDS 0268 DTCSnapshotRecordNumber par...5.5.10.1.5 Request parameter DTCSnapshotRecordNumber REQ_UDS 0268 DTCSnapshotRecordNumber parameter format shall be as per ISO 14229-1. | customer-input/pdf/CVS124.pdf | CVS124 > Page 42 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 42 Document section CVS124 > Page 42 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-005 |
| REQ_UDS-0098 | Internal Page 43 (90) 5.5.10.1.6 Request parameter DTCExtDataRecordNumber REQ_UDS 0098 Table...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 43 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 43 Document section CVS124 > Page 43 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ_UDS-0270 | 5.5.10.1.8 Request parameter DTCSeverityMaskRecord REQ_UDS 0270 DTCSeverityMaskRecord paramet...5.5.10.1.8 Request parameter DTCSeverityMaskRecord REQ_UDS 0270 DTCSeverityMaskRecord parameter format shall be as per ISO 14229-1. | customer-input/pdf/CVS124.pdf | CVS124 > Page 43 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 43 Document section CVS124 > Page 43 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-005 |
| REQ_UDS-0271 | 5.5.10.1.9 Request parameter DTCSeverityMask REQ_UDS 0271 DTCSeverityMask parameter format sh...5.5.10.1.9 Request parameter DTCSeverityMask REQ_UDS 0271 DTCSeverityMask parameter format shall be as per ISO 14229-1. | customer-input/pdf/CVS124.pdf | CVS124 > Page 43 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 43 Document section CVS124 > Page 43 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-005 |
| REQ_UDS-0272 | 5.5.10.2 Positive response REQ_UDS 0272 5.5.10.2.1 Response parameter DTCStatusAvailabilityMa...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 43 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 43 Document section CVS124 > Page 43 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-005 |
| REQ_UDS-0274 | 5.5.10.2.2 Response parameter DTCFormatIdentifier REQ_UDS 0274 Response parameter DTCFormatId...5.5.10.2.2 Response parameter DTCFormatIdentifier REQ_UDS 0274 Response parameter DTCFormatIdentifier shall be as per ISO 14229-1. | customer-input/pdf/CVS124.pdf | CVS124 > Page 43 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 43 Document section CVS124 > Page 43 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-005 |
| REQ_UDS-0275 | 5.5.10.2.3 Response parameter DTCCount REQ_UDS 0275 Response parameter DTCCount shall be as p...5.5.10.2.3 Response parameter DTCCount REQ_UDS 0275 Response parameter DTCCount shall be as per ISO 14229-1. | customer-input/pdf/CVS124.pdf | CVS124 > Page 43 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 43 Document section CVS124 > Page 43 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-005 |
| REQ_UDS-0276 | Internal Page 44 (90) 5.5.10.2.4 Response parameter DTCAndStatusRecord REQ_UDS 0276 Response...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 44 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 44 Document section CVS124 > Page 44 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-005 |
| REQ_UDS-0277 | 5.5.10.2.5 Response parameter DTCRecord REQ_UDS 0277 Response parameter DTCRecord shall be as...5.5.10.2.5 Response parameter DTCRecord REQ_UDS 0277 Response parameter DTCRecord shall be as per ISO 14229-1. | customer-input/pdf/CVS124.pdf | CVS124 > Page 44 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 44 Document section CVS124 > Page 44 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-005 |
| REQ-AUTO-00626 | 5.5.10.2.6 Response parameter reportDTCSnapshotRecordByDTCNumber The snapshot data sub-functi...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 44 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 44 Document section CVS124 > Page 44 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-008 |
| REQ_UDS-0099 | REQ_UDS 0099 Table 55 – Snapshot data sub-function (0x04) positive response message content a...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 44 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 44 Document section CVS124 > Page 44 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ-AUTO-00628 | If a mechanic is working on the vehicle, the driveline shall report Not Ready and place the v...If a mechanic is working on the vehicle, the driveline shall report Not Ready and place the vehicle in the state PropulsionNotReady. | customer-input/pdf/CVS124.pdf | CVS124 > Page 46 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 46 Document section CVS124 > Page 46 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ-AUTO-00629 | Internal Page 49 (90) Range tion #54 ECU start-up and alive reasons Bits 0-3 (start-up reason...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 49 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 49 Document section CVS124 > Page 49 Supplier rationale Source classifies this as Non-functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00630 | dependent depend ent depende nt U #65+N+M- #66+N+M dataIdentifier 0x0000 – #67+N+M +P Data re...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 50 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 50 Document section CVS124 > Page 50 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-DIAG-007 |
| REQ_UDS-0304 | REQ_UDS 0304 DTCSnapshotRecordNumber#1 & DTCSnapshotRecordNumber#2 shall correspond to first...REQ_UDS 0304 DTCSnapshotRecordNumber#1 & DTCSnapshotRecordNumber#2 shall correspond to first time DTC happened and latest time DTC happened correspondingly. | customer-input/pdf/CVS124.pdf | CVS124 > Page 50 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 50 Document section CVS124 > Page 50 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0100 | Internal Page 51 (90) 5.5.10.2.7 Response parameter DTCExtDataRecordNumber REQ_UDS 0100 Table...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 51 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 51 Document section CVS124 > Page 51 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ-AUTO-00633 | Table 57 – Extended data sub-function (0x06) positive response message content and format Byt...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 51 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 51 Document section CVS124 > Page 51 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ-AUTO-00634 | Internal Page 52 (90) Byte Description Range Resolu tion This byte shall be set to value 2 an...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 52 | Needs Customer Clarification | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm the exact ECU designation/variant and the agreed item definition and boundary used for the risk analysis (TARA). | OP-001 | None | None | Unknown | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 52 Document section CVS124 > Page 52 Supplier rationale Flagged customer_clarification_needed=yes during extraction. Implementation approach Hold implementation; raise an open point and a clarification question. Acceptance condition Customer answers the linked open point. Responsibility assumption OEM / Customer Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00635 | For these ECUs these bytes shall contain default value 0xFF (all bytes).For these ECUs these bytes shall contain default value 0xFF (all bytes). | customer-input/pdf/CVS124.pdf | CVS124 > Page 52 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 52 Document section CVS124 > Page 52 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ-AUTO-00636 | Internal Page 53 (90) Byte Description Range Resolu tion 0: 0 m 1: 5 m (factor 5) … 426141286...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). | customer-input/pdf/CVS124.pdf | CVS124 > Page 53 | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. | OP-004 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 53 Document section CVS124 > Page 53 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| 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)...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 53 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 53 Document section CVS124 > Page 53 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0278 | 5.5.10.2.9 Response parameter FunctionalGroupIdentifier REQ_UDS 0278 Response parameter Funct...5.5.10.2.9 Response parameter FunctionalGroupIdentifier REQ_UDS 0278 Response parameter FunctionalGroupIdentifier shall be as per ISO 14229-1. | customer-input/pdf/CVS124.pdf | CVS124 > Page 53 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 53 Document section CVS124 > Page 53 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-005 |
| REQ_UDS-0279 | 5.5.10.2.10 Response parameter DTCSeverityAvailabilityMask REQ_UDS 0279 Response parameter DT...5.5.10.2.10 Response parameter DTCSeverityAvailabilityMask REQ_UDS 0279 Response parameter DTCSeverityAvailabilityMask shall be as per ISO 14229-1. | customer-input/pdf/CVS124.pdf | CVS124 > Page 53 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 53 Document section CVS124 > Page 53 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-005 |
| REQ_UDS-0280 | Internal Page 54 (90) 5.5.10.2.11 Response parameter DTCAndSeverityRecord REQ_UDS 0280 Respon...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 54 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 54 Document section CVS124 > Page 54 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-005 |
| REQ_UDS-0281 | 5.5.10.3 Negative response REQ_UDS 0281 5.5.10.3.1 Supported negative response codes REQ_UDS...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 54 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 54 Document section CVS124 > Page 54 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-005 |
| REQ_UDS-0102 | 5.5.11 InputOutputControlByIdentifier (0x2F) service 5.5.11.1 Request REQ_UDS 0283 5.5.11.1.1...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 54 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 54 Document section CVS124 > Page 54 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ_UDS-0103 | 5.5.11.1.2 Request parameter controlOptionRecord REQ_UDS 0103 Table 58 – Service 0x2F request...5.5.11.1.2 Request parameter controlOptionRecord REQ_UDS 0103 Table 58 – Service 0x2F request parameter controlOptionRecord description 1 inputOutputControlParameter M 2 .. | customer-input/pdf/CVS124.pdf | CVS124 > Page 54 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 54 Document section CVS124 > Page 54 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0104 | 2 + (m-1) controlState byte 1 : controlState byte m C : C 5.5.11.1.3 Request parameter inputO...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 54 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 54 Document section CVS124 > Page 54 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0284 | M 5.5.11.1.4 Request parameter controlEnableMaskRecord REQ_UDS 0284 ControlEnableMaskRecord p...M 5.5.11.1.4 Request parameter controlEnableMaskRecord REQ_UDS 0284 ControlEnableMaskRecord parameter format shall be as per ISO 14229-1. | customer-input/pdf/CVS124.pdf | CVS124 > Page 55 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 55 Document section CVS124 > Page 55 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-005 |
| REQ_UDS-0105 | 5.5.11.2 Positive response REQ_UDS 0285 5.5.11.3 Negative response REQ_UDS 0286 5.5.12 Routin...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”. | customer-input/pdf/CVS124.pdf | CVS124 > Page 55 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 55 Document section CVS124 > Page 55 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0106 | 5.5.12.1.2 Request parameter RoutineIdentifier REQ_UDS 0106 Request parameter routineIdentifi...5.5.12.1.2 Request parameter RoutineIdentifier REQ_UDS 0106 Request parameter routineIdentifier shall be as per ISO 14229-1. | customer-input/pdf/CVS124.pdf | CVS124 > Page 55 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 55 Document section CVS124 > Page 55 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-005 |
| REQ-AUTO-00648 | The routine IDs as listed in Table 61 are reserved by TRATON and shall not be used by the sys...The routine IDs as listed in Table 61 are reserved by TRATON and shall not be used by the system supplier. | customer-input/pdf/CVS124.pdf | CVS124 > Page 55 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 55 Document section CVS124 > Page 55 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-005 |
| REQ_UDS-0107 | Internal Page 56 (90) REQ_UDS 0107 Table 61 – Service 0x31 request parameter RoutineIdentifie...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 56 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 56 Document section CVS124 > Page 56 Supplier rationale Source classifies this as Cybersecurity control (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0288 | 5.5.12.1.3 Request parameter RoutineControlOptionRecord REQ_UDS 0288 Request parameter routin...5.5.12.1.3 Request parameter RoutineControlOptionRecord REQ_UDS 0288 Request parameter routineControlOptionRecord shall be as per ISO 14229-1. | customer-input/pdf/CVS124.pdf | CVS124 > Page 57 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 57 Document section CVS124 > Page 57 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-005 |
| REQ_UDS-0108 | 5.5.12.2 Positive response REQ_UDS 0289 5.5.12.3 Negative response REQ_UDS 0290 5.5.13 Reques...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 57 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 57 Document section CVS124 > Page 57 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ-AUTO-00652 | INFO_UDS 0017 In order to satisfy stability requirements, the erasing of the boot loader may...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 57 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 57 Document section CVS124 > Page 57 Supplier rationale Source classifies this as Non-functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0109 | REQ_UDS 0109 If the most recent Erase Memory routine request in the current session was made...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). | customer-input/pdf/CVS124.pdf | CVS124 > Page 57 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 57 Document section CVS124 > Page 57 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ_UDS-0110 | REQ_UDS 0110 Once the RequestDownload service has started, only services TesterPresent, ECURe...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 57 | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 57 Document section CVS124 > Page 57 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SDT-001 |
| REQ_UDS-0111 | Internal Page 58 (90) REQ_UDS 0111 If a non-permitted service is requested after the RequestD...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 58 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 58 Document section CVS124 > Page 58 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-UPD-003 |
| REQ_UDS-0112 | 5.5.13.1 Request REQ_UDS 0112 The server shall support service request formatted according to...5.5.13.1 Request REQ_UDS 0112 The server shall support service request formatted according to Table 62. | customer-input/pdf/CVS124.pdf | CVS124 > Page 58 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 58 Document section CVS124 > Page 58 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ_UDS-0113 | M 5.5.13.2 Request parameter dataFormatIdentifier REQ_UDS 0113 Table 63 – Service 0x34 reques...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 | customer-input/pdf/CVS124.pdf | CVS124 > Page 58 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 58 Document section CVS124 > Page 58 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0114 | Internal Page 59 (90) encryptingMethod: 0x0: no encryption 0x1: encryption on DSC 0x2 -0x7 :...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.. | customer-input/pdf/CVS124.pdf | CVS124 > Page 59 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 59 Document section CVS124 > Page 59 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0116 | #4 maxNumberOfBlockLength[] = [ byte #1 (MSB) byte #2 ] M M 0xFF 0xFF 5.5.13.5 Response param...#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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 59 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 59 Document section CVS124 > Page 59 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0117 | Internal Page 60 (90) 5.5.14 RequestUpload (0x35) 5.5.14.1 Request REQ_UDS 0117 Table 67 – Se...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 .. | customer-input/pdf/CVS124.pdf | CVS124 > Page 60 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 60 Document section CVS124 > Page 60 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0118 | M 5.5.14.1.1 Request parameter dataFormatIdentifier REQ_UDS 0118 Table 68 – Service 0x35 requ...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 | customer-input/pdf/CVS124.pdf | CVS124 > Page 60 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 60 Document section CVS124 > Page 60 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0119 | Internal Page 61 (90) 5.5.14.1.2 Request parameter addressAndLengthFormatIdentifier REQ_UDS 0...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 61 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 61 Document section CVS124 > Page 61 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ_UDS-0292 | 5.5.14.1.4 Request parameter memorySize REQ_UDS 0292 MemorySize parameter definition shall be...5.5.14.1.4 Request parameter memorySize REQ_UDS 0292 MemorySize parameter definition shall be as per ISO 14229-1. | customer-input/pdf/CVS124.pdf | CVS124 > Page 61 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 61 Document section CVS124 > Page 61 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-005 |
| REQ_UDS-0120 | 5.5.14.2 Positive response REQ_UDS 0293 5.5.14.2.1 Response parameter lengthFormatIdentifier...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 61 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 61 Document section CVS124 > Page 61 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0294 | M 0 5.5.14.3 Negative response REQ_UDS 0294 Refer to ISO 14229-1 for negative response format...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 61 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 61 Document section CVS124 > Page 61 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-005 |
| REQ_UDS-0295 | 5.5.15 TransferData (0x36) service 5.5.15.1 Request REQ_UDS 02955.5.15 TransferData (0x36) service 5.5.15.1 Request REQ_UDS 0295 | customer-input/pdf/CVS124.pdf | CVS124 > Page 61 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 61 Document section CVS124 > Page 61 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0296 | Internal Page 62 (90) 5.5.15.1.1 Request parameter blockSequenceCounter REQ_UDS 0296 MemoryAd...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 62 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 62 Document section CVS124 > Page 62 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-005 |
| REQ_UDS-0297 | 5.5.15.1.2 Request parameter transferRequestParameterRecord REQ_UDS 0297 MemorySize parameter...5.5.15.1.2 Request parameter transferRequestParameterRecord REQ_UDS 0297 MemorySize parameter definition shall be as per ISO 14229-1. | customer-input/pdf/CVS124.pdf | CVS124 > Page 62 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 62 Document section CVS124 > Page 62 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-005 |
| 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 Su...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 62 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 62 Document section CVS124 > Page 62 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ_UDS-0123 | 5.5.16.2 Positive response REQ_UDS 0123 Table 72 – Service 0x37 positive response parameter d...5.5.16.2 Positive response REQ_UDS 0123 Table 72 – Service 0x37 positive response parameter description 1 RequestTransferExit Response SID M | customer-input/pdf/CVS124.pdf | CVS124 > Page 62 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 62 Document section CVS124 > Page 62 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0124 | Internal Page 63 (90) 5.5.16.2.1 Response parameter transferResponseParameterRecord REQ_UDS 0...Internal Page 63 (90) 5.5.16.2.1 Response parameter transferResponseParameterRecord REQ_UDS 0124 The transferRequestParameterRecord shall not be supported. | customer-input/pdf/CVS124.pdf | CVS124 > Page 63 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 63 Document section CVS124 > Page 63 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0125 | 5.5.16.3 Negative response REQ_UDS 0301 5.5.16.3.1 Supported negative response codes REQ_UDS...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 63 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 63 Document section CVS124 > Page 63 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ_UDS-0126 | 5.5.17.1 Request REQ_UDS 0303 5.5.17.1.1 Request message data-parameter definition REQ_UDS 01...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 63 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 63 Document section CVS124 > Page 63 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-DIAG-007 |
| REQ_UDS-0127 | 5.5.17.2 Positive response REQ_UDS 0127 Positive response shall be as per CVS32.5.5.17.2 Positive response REQ_UDS 0127 Positive response shall be as per CVS32. | customer-input/pdf/CVS124.pdf | CVS124 > Page 63 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 63 Document section CVS124 > Page 63 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0128 | 5.5.17.3 Negative response REQ_UDS 0128 Negative response shall be as per CVS32 5.5.17.3.1 Su...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 63 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 63 Document section CVS124 > Page 63 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-004 |
| REQ_UDS-0133 | Internal Page 64 (90) REQ_UDS 0133 The Authentication (0x29) service shall be implemented acc...Internal Page 64 (90) REQ_UDS 0133 The Authentication (0x29) service shall be implemented according to CVS31 . | customer-input/pdf/CVS124.pdf | CVS124 > Page 64 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 64 Document section CVS124 > Page 64 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-RBAC-004 |
| REQ_UDS-0134 | 5.5.18.1 Request REQ_UDS 0134 Refer to CVS31 .5.5.18.1 Request REQ_UDS 0134 Refer to CVS31 . | customer-input/pdf/CVS124.pdf | CVS124 > Page 64 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 64 Document section CVS124 > Page 64 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0135 | 5.5.18.2 Request parameter subFunction REQ_UDS 0135 Refer to CVS31 .5.5.18.2 Request parameter subFunction REQ_UDS 0135 Refer to CVS31 . | customer-input/pdf/CVS124.pdf | CVS124 > Page 64 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 64 Document section CVS124 > Page 64 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0136 | 5.5.18.3 Positive response REQ_UDS 0136 Refer to CVS31 .5.5.18.3 Positive response REQ_UDS 0136 Refer to CVS31 . | customer-input/pdf/CVS124.pdf | CVS124 > Page 64 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 64 Document section CVS124 > Page 64 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0137 | 5.5.18.4 Negative response REQ_UDS 0137 5.5.18.4.1 Supported negative response codes REQ_UDS...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 64 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 64 Document section CVS124 > Page 64 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-005 |
| REQ_UDS-0139 | Internal Page 65 (90) REQ_UDS 0139 For detailed error cases and the mapping to the correspond...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 65 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 65 Document section CVS124 > Page 65 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ_UDS-0140 | 5.5.19 RequestFileTransfer (0x38) service 5.5.19.1 Request REQ_UDS 0140 5.5.19.2 Request Para...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 65 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 65 Document section CVS124 > Page 65 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ-AUTO-00683 | If the file is not stored at the location the file shall be added.If the file is not stored at the location the file shall be added. | customer-input/pdf/CVS124.pdf | CVS124 > Page 65 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 65 Document section CVS124 > Page 65 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ-AUTO-00684 | M 0x04 ReadFile This value shall be used to read the file (upload) at the location defined by...M 0x04 ReadFile This value shall be used to read the file (upload) at the location defined by the filePathAndName parameter. | customer-input/pdf/CVS124.pdf | CVS124 > Page 65 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 65 Document section CVS124 > Page 65 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ-AUTO-00685 | U 0x05 ReadDir This value shall be used to read the directory defined in the filePathAndName...U 0x05 ReadDir This value shall be used to read the directory defined in the filePathAndName parameter. | customer-input/pdf/CVS124.pdf | CVS124 > Page 65 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 65 Document section CVS124 > Page 65 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ-AUTO-00686 | U 0x06 ResumeFile This value shall be used to resume downloading the file defined in the file...U 0x06 ResumeFile This value shall be used to resume downloading the file defined in the filePathAndName parameter at the returned filePosition indicator. | customer-input/pdf/CVS124.pdf | CVS124 > Page 65 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 65 Document section CVS124 > Page 65 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ-AUTO-00687 | The file specified in the filePathAndName shall already exist in the ECU’s file system.The file specified in the filePathAndName shall already exist in the ECU’s file system. | customer-input/pdf/CVS124.pdf | CVS124 > Page 65 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 65 Document section CVS124 > Page 65 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-HW-001 |
| REQ_UDS-0142 | Internal Page 66 (90) Byte value Description Cvt 0x07 – 0xFF ISO Reserved M 5.5.19.3 Request...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 66 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 66 Document section CVS124 > Page 66 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ_UDS-0143 | 5.5.19.4 Request Parameter dataFormatIdentifier REQ_UDS 0143 Table 75 – Service 0x38 request...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 66 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 66 Document section CVS124 > Page 66 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-DIAG-004 |
| REQ_UDS-0147 | Internal Page 67 (90) REQ_UDS 0147 The programming preconditions shall be agreed with the veh...Internal Page 67 (90) REQ_UDS 0147 The programming preconditions shall be agreed with the vehicle manufacturer. | customer-input/pdf/CVS124.pdf | CVS124 > Page 67 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 67 Document section CVS124 > Page 67 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-UPD-001 |
| REQ-AUTO-00691 | Preconditions to be discussed with the vehicle manufacturer shall include but not be limited...Preconditions to be discussed with the vehicle manufacturer shall include but not be limited to Diag safe state conditions. | customer-input/pdf/CVS124.pdf | CVS124 > Page 67 | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm the DIA / responsibility (RASIC/CIA) split for each cybersecurity work product before supplier scope is fixed. | OP-009 | None | OEM/Customer Review Interface | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 67 Document section CVS124 > Page 67 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-005 |
| REQ_UDS-0148 | REQ_UDS 0148 The decision on conditions of the programming precondition shall be based on min...REQ_UDS 0148 The decision on conditions of the programming precondition shall be based on minimum two independent sources of information. | customer-input/pdf/CVS124.pdf | CVS124 > Page 67 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 67 Document section CVS124 > Page 67 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-UPD-001 |
| REQ_UDS-0149 | REQ_UDS 0149 If information is not available for checking a programming precondition the prog...REQ_UDS 0149 If information is not available for checking a programming precondition the programming precondition shall be considered fulfilled. | customer-input/pdf/CVS124.pdf | CVS124 > Page 67 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 67 Document section CVS124 > Page 67 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-UPD-001 |
| REQ-AUTO-00694 | If the ECU received the information related to any of the conditions during the same driving...If the ECU received the information related to any of the conditions during the same driving cycle then it shall use that information. | customer-input/pdf/CVS124.pdf | CVS124 > Page 67 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 67 Document section CVS124 > Page 67 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-HW-001 |
| REQ_UDS-0150 | REQ_UDS 0150 This routine shall be supported in Extended session of both Application and Boot.REQ_UDS 0150 This routine shall be supported in Extended session of both Application and Boot. | customer-input/pdf/CVS124.pdf | CVS124 > Page 67 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 67 Document section CVS124 > Page 67 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ_UDS-0151 | 5.6.1.1 Request 5.6.1.2 Request parameter RoutineControlOptionRecord REQ_UDS 0151 Request par...5.6.1.1 Request 5.6.1.2 Request parameter RoutineControlOptionRecord REQ_UDS 0151 Request parameter RoutineControlOptionRecord shall not be supported. | customer-input/pdf/CVS124.pdf | CVS124 > Page 67 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 67 Document section CVS124 > Page 67 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0152 | REQ_UDS 0152 Request parameter routineControlType with value 0x03 (requestRoutineResults) sha...REQ_UDS 0152 Request parameter routineControlType with value 0x03 (requestRoutineResults) shall not be supported. | customer-input/pdf/CVS124.pdf | CVS124 > Page 67 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 67 Document section CVS124 > Page 67 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0153 | 5.6.1.3 Positive response REQ_UDS 0153 Table 76 – RoutineControl (CheckProgrammingPreconditio...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”). | customer-input/pdf/CVS124.pdf | CVS124 > Page 67 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 67 Document section CVS124 > Page 67 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-UPD-001 |
| REQ_UDS-0155 | Internal Page 68 (90) REQ_UDS 0155 Which ones of the programming precondition codes in Table...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 68 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 68 Document section CVS124 > Page 68 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-UPD-001 |
| REQ_UDS-0156 | REQ_UDS 0156 If all preconditions are satisfied, no routineStatus byte shall be reported.REQ_UDS 0156 If all preconditions are satisfied, no routineStatus byte shall be reported. | customer-input/pdf/CVS124.pdf | CVS124 > Page 68 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 68 Document section CVS124 > Page 68 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0157 | REQ_UDS 0157 Programming preconditions that do not map to one of the entries in Table 77 shal...REQ_UDS 0157 Programming preconditions that do not map to one of the entries in Table 77 shall be discussed with the vehicle manufacturer. | customer-input/pdf/CVS124.pdf | CVS124 > Page 68 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 68 Document section CVS124 > Page 68 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-UPD-001 |
| REQ-AUTO-00702 | Table 77 – Programming preconditions Hex Description Origin 0x01 Engine speed is not zero Def...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 .. | customer-input/pdf/CVS124.pdf | CVS124 > Page 68 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 68 Document section CVS124 > Page 68 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-UPD-003 |
| REQ_UDS-0158 | REQ_UDS 0158 The server shall respond with a positive response code without erasing memory if...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 69 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 69 Document section CVS124 > Page 69 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ-AUTO-00704 | INFO_UDS 0020 In order to satisfy stability requirements, the erasing of the boot loader may...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 69 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 69 Document section CVS124 > Page 69 Supplier rationale Source classifies this as Non-functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0159 | REQ_UDS 0159 In case the non volatile memory area is currently hosting a bootloader copy, mea...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 69 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 69 Document section CVS124 > Page 69 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-BOOT-002 |
| REQ_UDS-0160 | Internal Page 70 (90) REQ_UDS 0160 When the addressAndLengthFormatIdentifier parameter is set...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). | customer-input/pdf/CVS124.pdf | CVS124 > Page 70 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 70 Document section CVS124 > Page 70 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ_UDS-0161 | REQ_UDS 0161 The erasing of memory shall not prevent the client from starting a data transfer...REQ_UDS 0161 The erasing of memory shall not prevent the client from starting a data transfer using the TransferData (0x36) service, i.e. | customer-input/pdf/CVS124.pdf | CVS124 > Page 70 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 70 Document section CVS124 > Page 70 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SDT-001 |
| REQ-AUTO-00708 | the erasing of memory shall proceed in parallel with data transfer in case for ECUs implement...the erasing of memory shall proceed in parallel with data transfer in case for ECUs implementing Automatic erase. | customer-input/pdf/CVS124.pdf | CVS124 > Page 70 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 70 Document section CVS124 > Page 70 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-HW-001 |
| REQ_UDS-0162 | REQ_UDS 0162 This routine shall be supported in Programming session.REQ_UDS 0162 This routine shall be supported in Programming session. | customer-input/pdf/CVS124.pdf | CVS124 > Page 70 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 70 Document section CVS124 > Page 70 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-UPD-001 |
| REQ_UDS-0163 | 5.6.2.1 Request REQ_UDS 0163 Table 78 – RoutineIdentifier 0xFF00 description #1 RoutineContro...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 70 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 70 Document section CVS124 > Page 70 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0164 | Internal Page 71 (90) REQ_UDS 0164 Request parameter routineControlType with value 0x03 (requ...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 71 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 71 Document section CVS124 > Page 71 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-BOOT-003 |
| REQ-AUTO-00712 | 02, Module 2 (Application SW module) M 0x02 – 0xFF Physical memory range erase: Refer to ISO...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 71 | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 71 Document section CVS124 > Page 71 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-008 |
| REQ_UDS-0166 | REQ_UDS 0166 When the addressAndLengthFormatIdentifier is set to 0x01 the following defined m...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 ... | customer-input/pdf/CVS124.pdf | CVS124 > Page 71 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 71 Document section CVS124 > Page 71 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-BOOT-001 |
| REQ_UDS-0167 | 255 – System specific 5.6.2.3 Positive response REQ_UDS 0167 Table 80 – RoutineControl (Erase...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 | customer-input/pdf/CVS124.pdf | CVS124 > Page 71 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 71 Document section CVS124 > Page 71 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0168 | Internal Page 72 (90) REQ_UDS 0168 The routineResult byte values shall be as specified in Tab...Internal Page 72 (90) REQ_UDS 0168 The routineResult byte values shall be as specified in Table 81. | customer-input/pdf/CVS124.pdf | CVS124 > Page 72 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 72 Document section CVS124 > Page 72 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0169 | Internal Page 74 (90) #2 routineControlType (StartRoutine) 0x01 #3 routineIdentifier (MSB) 0x...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 74 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 74 Document section CVS124 > Page 74 Supplier rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0170 | REQ_UDS 0170 If authenticity verification is valid the server shall initiate all necessary st...REQ_UDS 0170 If authenticity verification is valid the server shall initiate all necessary steps for installation of the received file. | customer-input/pdf/CVS124.pdf | CVS124 > Page 74 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 74 Document section CVS124 > Page 74 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-DAI-004 |
| REQ_UDS-0171 | REQ_UDS 0171 The server shall send a response to RoutineIdentifier 0x2401 Software Installati...REQ_UDS 0171 The server shall send a response to RoutineIdentifier 0x2401 Software Installation without any further inputs from the client. | customer-input/pdf/CVS124.pdf | CVS124 > Page 74 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 74 Document section CVS124 > Page 74 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ_UDS-0172 | REQ_UDS 0172 If authenticity verification fails the server shall send the positive response w...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). | customer-input/pdf/CVS124.pdf | CVS124 > Page 74 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 74 Document section CVS124 > Page 74 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-DAI-004 |
| REQ_UDS-0173 | REQ_UDS 0173 This routine shall be supported in Programming session.REQ_UDS 0173 This routine shall be supported in Programming session. | customer-input/pdf/CVS124.pdf | CVS124 > Page 74 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 74 Document section CVS124 > Page 74 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-UPD-001 |
| REQ_UDS-0174 | 5.6.3.1 Request REQ_UDS 0174 Request parameter RoutineControlOptionRecord shall not be suppor...5.6.3.1 Request REQ_UDS 0174 Request parameter RoutineControlOptionRecord shall not be supported. | customer-input/pdf/CVS124.pdf | CVS124 > Page 74 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 74 Document section CVS124 > Page 74 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0175 | Internal Page 75 (90) 5.6.3.2 Positive Response REQ_UDS 0175 Positive responses to RoutineCon...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 75 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 75 Document section CVS124 > Page 75 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ_UDS-0176 | Description Cvt Values #1 RoutineControl Request SID M 0x71 #2 routineControlType (requestRou...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 75 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 75 Document section CVS124 > Page 75 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-DAI-002 |
| REQ_UDS-0177 | REQ_UDS 0177 AuthenticityVerificationStatus bit 7-6 (AuthenticityStatus) shall remain as 0x0...REQ_UDS 0177 AuthenticityVerificationStatus bit 7-6 (AuthenticityStatus) shall remain as 0x0 (Software Authenticity Invalid) until the verification completes. | customer-input/pdf/CVS124.pdf | CVS124 > Page 75 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 75 Document section CVS124 > Page 75 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-DAI-003 |
| REQ_UDS-0178 | REQ_UDS 0178 If no authenticity verification will take place as part of RoutineIdentifier, th...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). | customer-input/pdf/CVS124.pdf | CVS124 > Page 75 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 75 Document section CVS124 > Page 75 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-DAI-002 |
| REQ_UDS-0179 | Internal Page 76 (90) 0x1: Authenticity Verification Successful 0x2: Authenticity Verificatio...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 76 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 76 Document section CVS124 > Page 76 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-DAI-002 |
| REQ_UDS-0180 | REQ_UDS 0180 SoftwareInstallationStatus bit 7-6 (InstallationStatus) shall remain as 0x0 (Ins...REQ_UDS 0180 SoftwareInstallationStatus bit 7-6 (InstallationStatus) shall remain as 0x0 (Installation On-going) until the installation completes. | customer-input/pdf/CVS124.pdf | CVS124 > Page 76 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 76 Document section CVS124 > Page 76 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0181 | Table 91 – SoftwareInstallationStatus Bit Bit Name Bit Values Description 7-6 InstallationSta...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 76 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 76 Document section CVS124 > Page 76 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ-AUTO-00729 | Information shall be provided in percentage.Information shall be provided in percentage. | customer-input/pdf/CVS124.pdf | CVS124 > Page 76 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 76 Document section CVS124 > Page 76 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ_UDS-0182 | REQ_UDS 0182 TimeRemaningEstimative shall inform the time estimative to complete the installa...REQ_UDS 0182 TimeRemaningEstimative shall inform the time estimative to complete the installation of the file. | customer-input/pdf/CVS124.pdf | CVS124 > Page 76 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 76 Document section CVS124 > Page 76 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ-AUTO-00731 | Information shall be provided in seconds.Information shall be provided in seconds. | customer-input/pdf/CVS124.pdf | CVS124 > Page 76 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 76 Document section CVS124 > Page 76 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ-AUTO-00732 | 5.6.3.3 Negative response INFO_UDS 0028 Whereas the result of the dependency check is returne...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 76 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 76 Document section CVS124 > Page 76 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ-AUTO-00733 | 5.6.4 Routine 0xFF01 – CheckProgrammingDependencies (check the flash programming) INFO_UDS 00...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 76 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 76 Document section CVS124 > Page 76 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-UPD-005 |
| REQ_UDS-0183 | Internal Page 77 (90) REQ_UDS 0183 The server shall check whether or not the individual modul...Internal Page 77 (90) REQ_UDS 0183 The server shall check whether or not the individual modules are complete and compatible with one another. | customer-input/pdf/CVS124.pdf | CVS124 > Page 77 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 77 Document section CVS124 > Page 77 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DIAG-003 |
| REQ-AUTO-00735 | In addition, a check shall be made to determine whether or not the software is compatible wit...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). | customer-input/pdf/CVS124.pdf | CVS124 > Page 77 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 77 Document section CVS124 > Page 77 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-008 |
| REQ_UDS-0184 | REQ_UDS 0184 The method used to check compatibility/consistency shall be determined by the su...REQ_UDS 0184 The method used to check compatibility/consistency shall be determined by the supplier in consultation with the vehicle manufacturer. | customer-input/pdf/CVS124.pdf | CVS124 > Page 77 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 77 Document section CVS124 > Page 77 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-DIAG-001 |
| REQ_UDS-0185 | REQ_UDS 0185 The consistency check shall be carried out solely by the server.REQ_UDS 0185 The consistency check shall be carried out solely by the server. | customer-input/pdf/CVS124.pdf | CVS124 > Page 77 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 77 Document section CVS124 > Page 77 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DIAG-003 |
| REQ_UDS-0186 | REQ_UDS 0186 The server shall verify the authenticity and integrity of the software as a part...REQ_UDS 0186 The server shall verify the authenticity and integrity of the software as a part of the consistency check. | customer-input/pdf/CVS124.pdf | CVS124 > Page 77 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 77 Document section CVS124 > Page 77 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DAI-003 |
| REQ_UDS-0187 | REQ_UDS 0187 The authenticity and integrity information shall be supplied to the server befor...REQ_UDS 0187 The authenticity and integrity information shall be supplied to the server before the software is updated. | customer-input/pdf/CVS124.pdf | CVS124 > Page 77 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 77 Document section CVS124 > Page 77 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DAI-003 |
| REQ_UDS-0188 | REQ_UDS 0188 The authenticity and integrity check shall be carried out solely by the server.REQ_UDS 0188 The authenticity and integrity check shall be carried out solely by the server. | customer-input/pdf/CVS124.pdf | CVS124 > Page 77 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 77 Document section CVS124 > Page 77 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DAI-004 |
| REQ_UDS-0189 | REQ_UDS 0189 This routine shall be supported in Programming session.REQ_UDS 0189 This routine shall be supported in Programming session. | customer-input/pdf/CVS124.pdf | CVS124 > Page 77 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 77 Document section CVS124 > Page 77 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-UPD-001 |
| REQ_UDS-0190 | 5.6.4.1 Request REQ_UDS 0190 The server shall support RoutineControl (CheckProgrammingDepende...5.6.4.1 Request REQ_UDS 0190 The server shall support RoutineControl (CheckProgrammingDependencies) service request formatted according to Table 92. | customer-input/pdf/CVS124.pdf | CVS124 > Page 77 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 77 Document section CVS124 > Page 77 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-UPD-003 |
| REQ_UDS-0191 | Table 92 – RoutineIdentifier 0xFF01 description Byte Description Cvt Hex #1 RoutineControl Re...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 77 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 77 Document section CVS124 > Page 77 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0192 | Internal Page 78 (90) 5.6.4.2 Positive response REQ_UDS 0192 Positive responses to RoutineCon...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 78 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 78 Document section CVS124 > Page 78 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-UPD-003 |
| REQ_UDS-0193 | Table 93 – RoutineControl (CheckProgrammingDependencies) positive response format #1 RoutineC...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 78 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 78 Document section CVS124 > Page 78 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-UPD-001 |
| REQ-AUTO-00746 | Table 94 – CheckProgrammingDependencies routineStatusRecord results 0x00 correctResult M 0x01...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 78 | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 78 Document section CVS124 > Page 78 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-UPD-003 |
| REQ_UDS-0194 | Table 96 – Positive response: server → client #1 RoutineControl Response SID 0x71 #2 routineC...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 79 | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 79 Document section CVS124 > Page 79 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-UPD-005 |
| REQ_UDS-0195 | REQ_UDS 0195 This routine shall be supported in all sessions of Application and Boot.REQ_UDS 0195 This routine shall be supported in all sessions of Application and Boot. | customer-input/pdf/CVS124.pdf | CVS124 > Page 79 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 79 Document section CVS124 > Page 79 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ_UDS-0196 | Internal Page 80 (90) 5.7 Fault memory requirements 5.7.1 DTC status bits REQ_UDS 0196 Table...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 80 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 80 Document section CVS124 > Page 80 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-DIAG-006 |
| REQ_UDS-0198 | REQ_UDS 0198 The occurrence counter minimum value shall be zero (0).REQ_UDS 0198 The occurrence counter minimum value shall be zero (0). | customer-input/pdf/CVS124.pdf | CVS124 > Page 80 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 80 Document section CVS124 > Page 80 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0199 | REQ_UDS 0199 The occurrence counter maximum value shall be 126.REQ_UDS 0199 The occurrence counter maximum value shall be 126. | customer-input/pdf/CVS124.pdf | CVS124 > Page 80 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 80 Document section CVS124 > Page 80 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0200 | REQ_UDS 0200 The occurrence counter default value shall be zero (0).REQ_UDS 0200 The occurrence counter default value shall be zero (0). | customer-input/pdf/CVS124.pdf | CVS124 > Page 80 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 80 Document section CVS124 > Page 80 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0201 | REQ_UDS 0201 The occurrence counter shall increment by one (1) only.REQ_UDS 0201 The occurrence counter shall increment by one (1) only. | customer-input/pdf/CVS124.pdf | CVS124 > Page 80 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 80 Document section CVS124 > Page 80 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0202 | REQ_UDS 0202 The occurrence counter shall increment if it’s value is not at it’s maximum valu...REQ_UDS 0202 The occurrence counter shall increment if it’s value is not at it’s maximum value already. | customer-input/pdf/CVS124.pdf | CVS124 > Page 80 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 80 Document section CVS124 > Page 80 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DIAG-003 |
| REQ_UDS-0203 | REQ_UDS 0203 The occurrence counter shall increment at a change of DTC status bits 0 testFail...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 80 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 80 Document section CVS124 > Page 80 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0204 | Internal Page 81 (90) REQ_UDS 0204 The occurrence counter shall increment at a change of DTC...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 81 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 81 Document section CVS124 > Page 81 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0205 | REQ_UDS 0205 The occurrence counter shall increment at a change of DTC status bit 3 confirmed...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 81 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 81 Document section CVS124 > Page 81 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0206 | REQ_UDS 0206 The occurrence counter value 127 shall be defined as "errors with the counter".REQ_UDS 0206 The occurrence counter value 127 shall be defined as "errors with the counter". | customer-input/pdf/CVS124.pdf | CVS124 > Page 81 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 81 Document section CVS124 > Page 81 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0207 | REQ_UDS 0207 The timestamp default value shall be a 0xFF in each data.REQ_UDS 0207 The timestamp default value shall be a 0xFF in each data. | customer-input/pdf/CVS124.pdf | CVS124 > Page 81 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 81 Document section CVS124 > Page 81 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0208 | REQ_UDS 0208 The timestamp is presented in SAE J1939-71 format without local hour/minute offs...REQ_UDS 0208 The timestamp is presented in SAE J1939-71 format without local hour/minute offsets. | customer-input/pdf/CVS124.pdf | CVS124 > Page 81 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 81 Document section CVS124 > Page 81 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0209 | REQ_UDS 0209 In SAE J1939-71 section “PGN 65254 Time/Date”, the following format is specified...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 | customer-input/pdf/CVS124.pdf | CVS124 > Page 81 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 81 Document section CVS124 > Page 81 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0210 | Internal Page 82 (90) 5.7.3.1 Latest occurrence REQ_UDS 0210 The latest occurrence shall be u...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 82 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 82 Document section CVS124 > Page 82 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0211 | REQ_UDS 0211 If occurrence counter is set to 1, the timestamp of the latest occurrence shall...REQ_UDS 0211 If occurrence counter is set to 1, the timestamp of the latest occurrence shall be set to 0xFF. | customer-input/pdf/CVS124.pdf | CVS124 > Page 82 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 82 Document section CVS124 > Page 82 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0212 | 5.7.3.2 First occurrence REQ_UDS 0212 The first occurrence shall be updated at the first chan...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 82 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 82 Document section CVS124 > Page 82 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0213 | REQ_UDS 0213 The vehicle distance shall be represented by a four byte integer, big endian, wi...REQ_UDS 0213 The vehicle distance shall be represented by a four byte integer, big endian, with five meter per bit (5m/bit). | customer-input/pdf/CVS124.pdf | CVS124 > Page 82 | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 82 Document section CVS124 > Page 82 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0214 | REQ_UDS 0214 If all sources of vehicle distance information present no current data, the dist...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 82 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 82 Document section CVS124 > Page 82 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0215 | 5.7.4.1 Latest occurrence REQ_UDS 0215 The latest distance value is updated at a change of DT...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 82 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 82 Document section CVS124 > Page 82 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0217 | 5.7.4.2 First occurrence REQ_UDS 0217 The first distance value is updated at the first change...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 | customer-input/pdf/CVS124.pdf | CVS124 > Page 82 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 82 Document section CVS124 > Page 82 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0218 | REQ_UDS 0218 The operational hours are presented by a four byte integer, big endian, with , h...REQ_UDS 0218 The operational hours are presented by a four byte integer, big endian, with , half second per bit (0,5s/bit). | customer-input/pdf/CVS124.pdf | CVS124 > Page 83 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 83 Document section CVS124 > Page 83 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0219 | REQ_UDS 0219 If all sources of operational hours information present no current data, the ope...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 83 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 83 Document section CVS124 > Page 83 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0220 | 5.7.5.1 Latest occurrence REQ_UDS 0220 The latest operational hours value is updated at a cha...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 83 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 83 Document section CVS124 > Page 83 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0221 | REQ_UDS 0221 The latest operational hours value is updated at a change of DTC status bit 0 (t...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 83 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 83 Document section CVS124 > Page 83 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0222 | 5.7.5.2 First occurrence REQ_UDS 0222 The first operational hours value is updated at the fir...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 83 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 83 Document section CVS124 > Page 83 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0223 | 5.9 Performance requirements on CAN REQ_UDS 0223 The server shall be available for complete d...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 83 | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | Diagnostic security | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 83 Document section CVS124 > Page 83 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Diagnostic security | Interface: None | SSR: SSR-RBAC-001 |
| REQ_UDS-0224 | REQ_UDS 0224 If diagnostic data is not available in time the ECU should respond with NRC 0x78...REQ_UDS 0224 If diagnostic data is not available in time the ECU should respond with NRC 0x78 (requestCorrectlyReceived-ResponsePending) for maximum allowed time. | customer-input/pdf/CVS124.pdf | CVS124 > Page 83 | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm or correct the stated supplier assumption. | - | Diagnostic security | None | High | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 83 Document section CVS124 > Page 83 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Diagnostic security | Interface: None | SSR: SSR-RBAC-001 |
| REQ-AUTO-00776 | for Linux based systems still running in boot, the server should indicate with DID 0xF1AD tha...for Linux based systems still running in boot, the server should indicate with DID 0xF1AD that it is running in boot. | customer-input/pdf/CVS124.pdf | CVS124 > Page 83 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 83 Document section CVS124 > Page 83 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-003 |
| REQ_UDS-0225 | 5.10 Session layer performance requirements REQ_UDS 0225 For P2Server, the minimum value shal...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 83 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 83 Document section CVS124 > Page 83 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0226 | REQ_UDS 0226 For P2Client, a value of 150 ms shall be used.REQ_UDS 0226 For P2Client, a value of 150 ms shall be used. | customer-input/pdf/CVS124.pdf | CVS124 > Page 83 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 83 Document section CVS124 > Page 83 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0227 | Internal Page 84 (90) REQ_UDS 0227 For P2*Server, the minimum value shall be 0ms, the maximum...Internal Page 84 (90) REQ_UDS 0227 For P2*Server, the minimum value shall be 0ms, the maximum value shall be 4000ms. | customer-input/pdf/CVS124.pdf | CVS124 > Page 84 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 84 Document section CVS124 > Page 84 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DIAG-003 |
| REQ_UDS-0228 | REQ_UDS 0228 For P2*Client, the value estimation given in ISO 14229-2 shall be used.REQ_UDS 0228 For P2*Client, the value estimation given in ISO 14229-2 shall be used. | customer-input/pdf/CVS124.pdf | CVS124 > Page 84 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 84 Document section CVS124 > Page 84 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DIAG-005 |
| REQ_UDS-0229 | REQ_UDS 0229 The value for P4_Server_max shall be maximum 30 seconds.REQ_UDS 0229 The value for P4_Server_max shall be maximum 30 seconds. | customer-input/pdf/CVS124.pdf | CVS124 > Page 84 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 84 Document section CVS124 > Page 84 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DIAG-001 |
| REQ_UDS-0230 | REQ_UDS 0230 The system supplier shall document the implemented value for P4_Server_max.REQ_UDS 0230 The system supplier shall document the implemented value for P4_Server_max. | customer-input/pdf/CVS124.pdf | CVS124 > Page 84 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 84 Document section CVS124 > Page 84 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-DIAG-002 |
| REQ_UDS-0339 | Internal Page 90 (90) Annex C (informative) Change history Release date Changes 2025-12 New r...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. | customer-input/pdf/CVS124.pdf | CVS124 > Page 90 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 90 Document section CVS124 > Page 90 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ_UDS-0003 | Modified requirements: REQ_UDS 0003: Added semantic Identifier DIDs, changed the NodeUID DID...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 | customer-input/pdf/CVS124.pdf | CVS124 > Page 90 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | None | Pending | DetailsSource customer-input/pdf/CVS124.pdf / page 90 Document section CVS124 > Page 90 Supplier rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00785 | RBAC for diagnostics Foreword This Commercial Vehicle Standard (“CVS151”) contains requiremen...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. | customer-input/pdf/CVS151.pdf | CVS151 > Page 1 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 1 Document section CVS151 > Page 1 Supplier rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00786 | Any review of this CVS151 shall only be done in agreement with the involved TRATON Group comm...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”. | customer-input/pdf/CVS151.pdf | CVS151 > Page 1 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 1 Document section CVS151 > Page 1 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-009 |
| REQ-AUTO-00787 | The User shall apply the latest version of this CVS151.The User shall apply the latest version of this CVS151. | customer-input/pdf/CVS151.pdf | CVS151 > Page 1 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 1 Document section CVS151 > Page 1 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ-AUTO-00788 | Page 3 1 Scope Concepts such as secure-update (CVS37) requires Role Based Access Control (RBA...Page 3 1 Scope Concepts such as secure-update (CVS37) requires Role Based Access Control (RBAC) for diagnostics (UDS). | customer-input/pdf/CVS151.pdf | CVS151 > Page 3 | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm or correct the stated supplier assumption. | - | Diagnostic security | None | High | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 3 Document section CVS151 > Page 3 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Diagnostic security | Interface: None | SSR: SSR-RBAC-001 |
| REQ-AUTO-00789 | RBAC_INFO 2 Before a client can execute diagnostics services that are under RBAC, the client...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. | customer-input/pdf/CVS151.pdf | CVS151 > Page 4 | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 4 Document section CVS151 > Page 4 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-005 |
| REQ-AUTO-00790 | RBAC_REQ 1 Each RBACC shall only contain one role-configuration per each supported role.RBAC_REQ 1 Each RBACC shall only contain one role-configuration per each supported role. | customer-input/pdf/CVS151.pdf | CVS151 > Page 4 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 4 Document section CVS151 > Page 4 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-RBAC-006 |
| REQ-AUTO-00791 | RBAC_REQ 2 If conflicting/overlapping rules are found within a role-configuration, the server...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. | customer-input/pdf/CVS151.pdf | CVS151 > Page 5 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 5 Document section CVS151 > Page 5 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00792 | RBAC_REQ 3 If a matching allow/deny rule is found and all the rule settings are fulfilled, th...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. | customer-input/pdf/CVS151.pdf | CVS151 > Page 5 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 5 Document section CVS151 > Page 5 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00793 | RBAC_REQ 4 If a matching rule is found and not all the rule settings are fulfilled, the serve...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. | customer-input/pdf/CVS151.pdf | CVS151 > Page 5 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 5 Document section CVS151 > Page 5 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00794 | RBAC_REQ 5 The server shall deny a request if no matching rule is found on RBACC.RBAC_REQ 5 The server shall deny a request if no matching rule is found on RBACC. | customer-input/pdf/CVS151.pdf | CVS151 > Page 5 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 5 Document section CVS151 > Page 5 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00795 | RBAC_INFO 10 All RBACC ALLOW rules have a setting that dictates if a request, matching the ru...RBAC_INFO 10 All RBACC ALLOW rules have a setting that dictates if a request, matching the rule, must be 14229-1:2020). | customer-input/pdf/CVS151.pdf | CVS151 > Page 5 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 5 Document section CVS151 > Page 5 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-RBAC-006 |
| REQ-AUTO-00796 | RBAC_REQ 6 The server shall evaluate each role-configuration independently from each other.RBAC_REQ 6 The server shall evaluate each role-configuration independently from each other. | customer-input/pdf/CVS151.pdf | CVS151 > Page 6 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 6 Document section CVS151 > Page 6 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00797 | RBAC_REQ 27 The server shall require that requests are authenticated for allow rules, using e...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). | customer-input/pdf/CVS151.pdf | CVS151 > Page 6 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 6 Document section CVS151 > Page 6 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00798 | Page 7 RBACC Role-configuration role Pattern-rule DENY Pattern-rule ALLOW DID-rule DENY DID-r...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)) } | customer-input/pdf/CVS151.pdf | CVS151 > Page 7 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 7 Document section CVS151 > Page 7 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00799 | RBAC_REQ 8 The server shall support in the version field two octets.RBAC_REQ 8 The server shall support in the version field two octets. | customer-input/pdf/CVS151.pdf | CVS151 > Page 8 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 8 Document section CVS151 > Page 8 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00800 | RBAC_REQ 9 The server shall support major version value 3 and minor version value 0.RBAC_REQ 9 The server shall support major version value 3 and minor version value 0. | customer-input/pdf/CVS151.pdf | CVS151 > Page 8 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 8 Document section CVS151 > Page 8 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00801 | RBAC_INFO 19 If other versions shall be supported is out of the scope of this document and sh...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. | customer-input/pdf/CVS151.pdf | CVS151 > Page 8 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 8 Document section CVS151 > Page 8 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-RBAC-006 |
| REQ-AUTO-00802 | RBAC_REQ 10 Before RBACC is stored, the server shall verify that the server supports the stru...RBAC_REQ 10 Before RBACC is stored, the server shall verify that the server supports the structure indicated in the version number. | customer-input/pdf/CVS151.pdf | CVS151 > Page 8 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 8 Document section CVS151 > Page 8 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00803 | If the version number does not comply with the server implementation, the server shall reject...If the version number does not comply with the server implementation, the server shall reject storing the data. | customer-input/pdf/CVS151.pdf | CVS151 > Page 8 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 8 Document section CVS151 > Page 8 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00804 | RBAC_REQ 11 The server shall report the currently stored RBACC’s version via diagnostics.RBAC_REQ 11 The server shall report the currently stored RBACC’s version via diagnostics. | customer-input/pdf/CVS151.pdf | CVS151 > Page 8 | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 8 Document section CVS151 > Page 8 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00805 | RBAC_REQ 12 The server shall support 16 octets in the rbacc-id field.RBAC_REQ 12 The server shall support 16 octets in the rbacc-id field. | customer-input/pdf/CVS151.pdf | CVS151 > Page 8 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 8 Document section CVS151 > Page 8 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00806 | RBAC_REQ 13 The server shall report the currently stored RBACC’s rbacc-id via diagnostics.RBAC_REQ 13 The server shall report the currently stored RBACC’s rbacc-id via diagnostics. | customer-input/pdf/CVS151.pdf | CVS151 > Page 8 | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 8 Document section CVS151 > Page 8 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00807 | RBAC_REQ 14 The server shall support role-configurations using 32-bit unsigned integer.RBAC_REQ 14 The server shall support role-configurations using 32-bit unsigned integer. | customer-input/pdf/CVS151.pdf | CVS151 > Page 8 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 8 Document section CVS151 > Page 8 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00808 | Page 9 3.7 pattern-rules RBAC_REQ 15 The server shall support for every entry in the pattern-...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. | customer-input/pdf/CVS151.pdf | CVS151 > Page 9 | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | Diagnostic security | None | High | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 9 Document section CVS151 > Page 9 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Diagnostic security | Interface: None | SSR: SSR-RBAC-001 |
| REQ-AUTO-00809 | RBAC_REQ 16 The server shall support the pattern-rule setting according to Table 1.RBAC_REQ 16 The server shall support the pattern-rule setting according to Table 1. | customer-input/pdf/CVS151.pdf | CVS151 > Page 9 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 9 Document section CVS151 > Page 9 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00810 | Table 1 – Pattern Rule Settings Bit index Name Description 0 Reserved Reserved 1 UDS 0 == Thi...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. | customer-input/pdf/CVS151.pdf | CVS151 > Page 9 | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 9 Document section CVS151 > Page 9 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DIAG-003 |
| REQ-AUTO-00811 | 4-7 N/A Reserved for future use 3.8 did-rules RBAC_REQ 17 The server shall support for every...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. | customer-input/pdf/CVS151.pdf | CVS151 > Page 9 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 9 Document section CVS151 > Page 9 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00812 | RBAC_REQ 18 The byte order for DID shall be big endian.RBAC_REQ 18 The byte order for DID shall be big endian. | customer-input/pdf/CVS151.pdf | CVS151 > Page 9 | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 9 Document section CVS151 > Page 9 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-RBAC-006 |
| REQ-AUTO-00813 | RBAC_REQ 19 The server shall support the did-rule setting according to Table 2.RBAC_REQ 19 The server shall support the did-rule setting according to Table 2. | customer-input/pdf/CVS151.pdf | CVS151 > Page 9 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 9 Document section CVS151 > Page 9 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00814 | Page 10 Table 2 – DID Rule Settings Bit index Name Description 0 Reserved Reserved 1 UDS 0 ==...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. | customer-input/pdf/CVS151.pdf | CVS151 > Page 10 | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 10 Document section CVS151 > Page 10 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DIAG-003 |
| REQ-AUTO-00815 | 4 Read 0 == This rule is not applicable when the DID is being read 1 == This rule is applicab...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. | customer-input/pdf/CVS151.pdf | CVS151 > Page 10 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 10 Document section CVS151 > Page 10 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00816 | RBAC_REQ 21 The server shall support the rid-rule setting according to Table 3.RBAC_REQ 21 The server shall support the rid-rule setting according to Table 3. | customer-input/pdf/CVS151.pdf | CVS151 > Page 10 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 10 Document section CVS151 > Page 10 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00817 | Page 11 Table 3 – RID Rule Setting Bit index Name Description 0 Reserved Reserved 1 UDS 0 ==...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. | customer-input/pdf/CVS151.pdf | CVS151 > Page 11 | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 11 Document section CVS151 > Page 11 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DIAG-003 |
| REQ-AUTO-00818 | RBAC_REQ 22 If conflicting/overlapping rules are found between the client certificate D-RBACC...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. | customer-input/pdf/CVS151.pdf | CVS151 > Page 11 | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier. | OP-003 | Certificate handling | None | High | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 11 Document section CVS151 > Page 11 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Certificate handling | Interface: None | SSR: SSR-KEY-002 |
| REQ-AUTO-00819 | Page 12 RBAC_REQ 23 The server shall interpret the extnValue (see snipped above) as of one in...Page 12 RBAC_REQ 23 The server shall interpret the extnValue (see snipped above) as of one instance of a RBACC (see 3.3). | customer-input/pdf/CVS151.pdf | CVS151 > Page 12 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 12 Document section CVS151 > Page 12 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00820 | It can also be useful if you want to add or remove access rights from a client/tester, that n...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. | customer-input/pdf/CVS151.pdf | CVS151 > Page 12 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 12 Document section CVS151 > Page 12 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-003 |
| REQ-AUTO-00821 | 3.11 ECU-Diagnostics-Role Extension RBAC_REQ 36 The server shall exert the RBACC roles based...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. | customer-input/pdf/CVS151.pdf | CVS151 > Page 12 | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | Certificate handling | None | High | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 12 Document section CVS151 > Page 12 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Certificate handling | Interface: None | SSR: SSR-KEY-002 |
| REQ-AUTO-00822 | Page 13 Figure 3 – Logic Overview RBAC_REQ 35 The server shall implement RBAC internal logic...Page 13 Figure 3 – Logic Overview RBAC_REQ 35 The server shall implement RBAC internal logic as per Figure 4. | customer-input/pdf/CVS151.pdf | CVS151 > Page 13 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 13 Document section CVS151 > Page 13 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-004 |
| REQ-AUTO-00823 | RBAC_REQ 32 The server shall implement RBAC pattern rule evaluation logic as per Figure 5.RBAC_REQ 32 The server shall implement RBAC pattern rule evaluation logic as per Figure 5. | customer-input/pdf/CVS151.pdf | CVS151 > Page 15 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 15 Document section CVS151 > Page 15 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-004 |
| REQ-AUTO-00824 | E.g: For the evaluate pattern the rule setting Confidentiality is set to 0x01 (Confidentialit...E.g: For the evaluate pattern the rule setting Confidentiality is set to 0x01 (Confidentiality is required). | customer-input/pdf/CVS151.pdf | CVS151 > Page 16 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 16 Document section CVS151 > Page 16 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ-AUTO-00825 | RBAC_REQ 33 The server shall implement RBAC did rule evaluate as per Figure 6.RBAC_REQ 33 The server shall implement RBAC did rule evaluate as per Figure 6. | customer-input/pdf/CVS151.pdf | CVS151 > Page 16 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 16 Document section CVS151 > Page 16 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00826 | Page 17 RBAC_REQ 34 The server shall implement RBAC rid rule evaluate as per Figure 7.Page 17 RBAC_REQ 34 The server shall implement RBAC rid rule evaluate as per Figure 7. | customer-input/pdf/CVS151.pdf | CVS151 > Page 17 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 17 Document section CVS151 > Page 17 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00827 | Meaning, role 0 is particularly useful for defining services, DIDs and RIDs that should be av...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. | customer-input/pdf/CVS151.pdf | CVS151 > Page 19 | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 19 Document section CVS151 > Page 19 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-RBAC-006 |
| REQ-AUTO-00828 | RBAC_REQ 24 The server shall allow requests that are contained in role 0 rules regardless of...RBAC_REQ 24 The server shall allow requests that are contained in role 0 rules regardless of the client authentication state. | customer-input/pdf/CVS151.pdf | CVS151 > Page 19 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 19 Document section CVS151 > Page 19 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00829 | RBAC_REQ 25 The server shall allow request that are contained in role 0 rule regardless if th...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). | customer-input/pdf/CVS151.pdf | CVS151 > Page 19 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 19 Document section CVS151 > Page 19 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00830 | RBAC_REQ 26 The server shall allow request that are contained in role 0 rule regardless of th...RBAC_REQ 26 The server shall allow request that are contained in role 0 rule regardless of the value of Confidentiality field setting. | customer-input/pdf/CVS151.pdf | CVS151 > Page 19 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 19 Document section CVS151 > Page 19 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00831 | RBAC_INFO 40 This means that in role 0 encryption is never required.RBAC_INFO 40 This means that in role 0 encryption is never required. | customer-input/pdf/CVS151.pdf | CVS151 > Page 19 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 19 Document section CVS151 > Page 19 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-RBAC-006 |
| REQ-AUTO-00832 | 3.14 Requests Specific Requirements 3.14.1 Diagnostic over USD 3.14.1.1 Authenticate 0x29 RBA...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. | customer-input/pdf/CVS151.pdf | CVS151 > Page 19 | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | Authentication | None | High | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 19 Document section CVS151 > Page 19 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Authentication | Interface: None | SSR: SSR-RBAC-002 |
| REQ-AUTO-00833 | RBAC_INFO 42 For 0x29 requests a corresponding matching rule in the RBACC is not required for...RBAC_INFO 42 For 0x29 requests a corresponding matching rule in the RBACC is not required for the server to accept the request. | customer-input/pdf/CVS151.pdf | CVS151 > Page 19 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 19 Document section CVS151 > Page 19 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00834 | 3.14.1.2 SecuredData Transmission 0x84 RBAC_REQ 29 The server shall evaluate the reported int...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. | customer-input/pdf/CVS151.pdf | CVS151 > Page 19 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 19 Document section CVS151 > Page 19 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-004 |
| REQ-AUTO-00835 | RBAC_REQ 30 The server shall always allow reception of UDS SecuredDataTransmission 0x84 reque...RBAC_REQ 30 The server shall always allow reception of UDS SecuredDataTransmission 0x84 requests regardless of the RBACC settings. | customer-input/pdf/CVS151.pdf | CVS151 > Page 19 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 19 Document section CVS151 > Page 19 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00836 | RBAC_INFO 43 For 0x84 requests a corresponding matching rule in the RBACC is not required for...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. | customer-input/pdf/CVS151.pdf | CVS151 > Page 19 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 19 Document section CVS151 > Page 19 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00837 | Page 20 3.14.1.3 TesterPresent 0x3E RBAC_REQ 31 The server shall always allow reception of UD...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. | customer-input/pdf/CVS151.pdf | CVS151 > Page 20 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 20 Document section CVS151 > Page 20 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00838 | RBAC_INFO 44 For 0x3E requests a corresponding matching rule in the RBACC is not required for...RBAC_INFO 44 For 0x3E requests a corresponding matching rule in the RBACC is not required for the server to accept the request. | customer-input/pdf/CVS151.pdf | CVS151 > Page 20 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 20 Document section CVS151 > Page 20 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00839 | Page 26 Annex D DynamicallyDefineDataIdentifier When this service is being used, each DID inc...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). | customer-input/pdf/CVS151.pdf | CVS151 > Page 26 | Accept with Assumption | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm or correct the stated supplier assumption. | - | Certificate handling | None | High | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 26 Document section CVS151 > Page 26 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Certificate handling | Interface: None | SSR: SSR-KEY-002 |
| REQ-AUTO-00840 | The client must have read access for all included DIDs and have access to the service themsel...The client must have read access for all included DIDs and have access to the service themselves. | customer-input/pdf/CVS151.pdf | CVS151 > Page 26 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 26 Document section CVS151 > Page 26 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-008 |
| REQ-AUTO-00841 | When the client is performing the actual read operation (ReadDataByIdentifier [7]), the condi...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. | customer-input/pdf/CVS151.pdf | CVS151 > Page 26 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 26 Document section CVS151 > Page 26 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ-AUTO-00842 | Since reading of DIDs can be allowed by either a pattern-rule (starting with 22 [7]) and/or a...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. | customer-input/pdf/CVS151.pdf | CVS151 > Page 26 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/CVS151.pdf / page 26 Document section CVS151 > Page 26 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-00843 | Data Security Container base definition Foreword This Commercial Vehicle Standard (“CVS154”)...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. | customer-input/pdf/CVS154.pdf | CVS154 > Page 1 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 1 Document section CVS154 > Page 1 Supplier rationale Source classifies this as Cybersecurity control (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00844 | Any review of this CVS154 shall only be done in agreement with the involved TRATON Group comm...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”. | customer-input/pdf/CVS154.pdf | CVS154 > Page 1 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 1 Document section CVS154 > Page 1 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-009 |
| REQ-AUTO-00845 | The User shall apply the latest version of this CVS154.The User shall apply the latest version of this CVS154. | customer-input/pdf/CVS154.pdf | CVS154 > Page 1 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 1 Document section CVS154 > Page 1 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ-AUTO-00846 | This document shall be used accompanied with these specifications.This document shall be used accompanied with these specifications. | customer-input/pdf/CVS154.pdf | CVS154 > Page 3 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 3 Document section CVS154 > Page 3 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ-AUTO-00847 | DSC_BASE_REQ 37 The server shall support a DSC Metadata block containing version and id fields.DSC_BASE_REQ 37 The server shall support a DSC Metadata block containing version and id fields. | customer-input/pdf/CVS154.pdf | CVS154 > Page 5 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 5 Document section CVS154 > Page 5 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00848 | DSC_BASE_REQ 43 The server shall support the Major and Minor version as specified in 3.2.DSC_BASE_REQ 43 The server shall support the Major and Minor version as specified in 3.2. | customer-input/pdf/CVS154.pdf | CVS154 > Page 5 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 5 Document section CVS154 > Page 5 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00849 | DSC_BASE_REQ 29 The server shall support a DSC containing verificationEntries.DSC_BASE_REQ 29 The server shall support a DSC containing verificationEntries. | customer-input/pdf/CVS154.pdf | CVS154 > Page 5 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 5 Document section CVS154 > Page 5 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-VV-002 |
| REQ-AUTO-00850 | DSC_BASE_REQ 30 The server shall support a DSC containing encryptionEntries.DSC_BASE_REQ 30 The server shall support a DSC containing encryptionEntries. | customer-input/pdf/CVS154.pdf | CVS154 > Page 5 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 5 Document section CVS154 > Page 5 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00851 | DSC_BASE_REQ 31 The server shall support a DSC containing itemEntries.DSC_BASE_REQ 31 The server shall support a DSC containing itemEntries. | customer-input/pdf/CVS154.pdf | CVS154 > Page 5 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 5 Document section CVS154 > Page 5 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00852 | DSC_BASE_REQ 45 The server shall expect an ASN.1 SEQUENCE tag with length zero for verificati...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. | customer-input/pdf/CVS154.pdf | CVS154 > Page 5 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 5 Document section CVS154 > Page 5 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-VV-002 |
| REQ-AUTO-00853 | DSC_BASE_REQ 46 The server shall expect an ASN.1 SEQUENCE tag with length zero for encryption...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. | customer-input/pdf/CVS154.pdf | CVS154 > Page 5 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 5 Document section CVS154 > Page 5 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00854 | DSC_BASE_REQ 49 The server shall expect an ASN.1 SEQUENCE tag with length zero for ItemEntrie...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. | customer-input/pdf/CVS154.pdf | CVS154 > Page 5 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 5 Document section CVS154 > Page 5 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00855 | DSC_BASE_REQ 26 The server shall support an empty DSC containing only Metadata (version and i...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. | customer-input/pdf/CVS154.pdf | CVS154 > Page 5 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | OEM/Customer Review Interface | Low | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 5 Document section CVS154 > Page 5 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-VV-002 |
| REQ-AUTO-00856 | DSC_BASE_INFO 44 An empty DSC issued by client means that in addition to Metadata, the syntax...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. | customer-input/pdf/CVS154.pdf | CVS154 > Page 5 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 5 Document section CVS154 > Page 5 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ-AUTO-00857 | Page 6 DSC_BASE_INFO 33 A DSC containing only version and id states that verification and enc...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. | customer-input/pdf/CVS154.pdf | CVS154 > Page 6 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | OEM/Customer Review Interface | Low | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 6 Document section CVS154 > Page 6 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-VV-002 |
| REQ-AUTO-00858 | 3.1.1.1 HashCmp DSC_BASE_REQ 5 VerificationEntry hashCmp states that a hash comparison shall...3.1.1.1 HashCmp DSC_BASE_REQ 5 VerificationEntry hashCmp states that a hash comparison shall be used to verify the data. | customer-input/pdf/CVS154.pdf | CVS154 > Page 6 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 6 Document section CVS154 > Page 6 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-VV-001 |
| REQ-AUTO-00859 | However, the instance specification may state specialized actions: • Server processes each Ve...However, the instance specification may state specialized actions: • Server processes each VerificationEntry one by one. | customer-input/pdf/CVS154.pdf | CVS154 > Page 6 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 6 Document section CVS154 > Page 6 Supplier rationale Source classifies this as Non-functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00860 | Page 7 • hashAlgorithm: States which HashAlgorithm (see RFC 6234) shall be used for hashing t...Page 7 • hashAlgorithm: States which HashAlgorithm (see RFC 6234) shall be used for hashing the data to verify. | customer-input/pdf/CVS154.pdf | CVS154 > Page 7 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 7 Document section CVS154 > Page 7 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ-AUTO-00861 | • dataRanges: sequence of Range items - Range: Information on which data chunks that shall be...• dataRanges: sequence of Range items - Range: Information on which data chunks that shall be verified. | customer-input/pdf/CVS154.pdf | CVS154 > Page 7 | Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm responsibility and implementation method. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 7 Document section CVS154 > Page 7 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-CON-002 |
| REQ-AUTO-00862 | DSC_BASE_REQ 47 The server shall support the SHA512 HashAlgorithm as referred in 3.2 ASN1 def...DSC_BASE_REQ 47 The server shall support the SHA512 HashAlgorithm as referred in 3.2 ASN1 definition. | customer-input/pdf/CVS154.pdf | CVS154 > Page 7 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 7 Document section CVS154 > Page 7 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00863 | DSC_BASE_REQ 39 For crypto agility reasons, both of the choices shall be supported by the ser...DSC_BASE_REQ 39 For crypto agility reasons, both of the choices shall be supported by the server. | customer-input/pdf/CVS154.pdf | CVS154 > Page 7 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 7 Document section CVS154 > Page 7 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00864 | DSC_BASE_REQ 11 The initial counter value shall be set to 0 (zero).DSC_BASE_REQ 11 The initial counter value shall be set to 0 (zero). | customer-input/pdf/CVS154.pdf | CVS154 > Page 7 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 7 Document section CVS154 > Page 7 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ-AUTO-00865 | Range: Information on which data chunks that shall be decrypted.Range: Information on which data chunks that shall be decrypted. | customer-input/pdf/CVS154.pdf | CVS154 > Page 8 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 8 Document section CVS154 > Page 8 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ-AUTO-00866 | 3.2 DSC ASN.1 definition DSC_BASE_REQ 41 The structure version for this document release shal...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 } | customer-input/pdf/CVS154.pdf | CVS154 > Page 9 | Needs Customer Clarification | Needs customer clarification. The requirement implies customer-owned infrastructure, approval, or a responsibility split that is not yet available. | Scope and responsibility for each listed requirement. | OP-011 | None | OEM/Customer Review Interface | Unknown | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 9 Document section CVS154 > Page 9 Supplier rationale Flagged customer_clarification_needed=yes during extraction. Implementation approach Hold implementation; raise an open point and a clarification question. Acceptance condition Customer answers the linked open point. Responsibility assumption OEM / Customer Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: None |
| REQ-AUTO-00867 | DSC_BASE_REQ 19 Upon reception of a DSC to the server, before the DSC is stored in NVM, the D...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. | customer-input/pdf/CVS154.pdf | CVS154 > Page 10 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 10 Document section CVS154 > Page 10 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-COM-006 |
| REQ-AUTO-00868 | DSC_BASE_REQ 51 The length of the version field shall be verified.DSC_BASE_REQ 51 The length of the version field shall be verified. | customer-input/pdf/CVS154.pdf | CVS154 > Page 10 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 10 Document section CVS154 > Page 10 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ_DSC_BASE-20 | REQ_DSC_BASE 20 The version shall be verified with the servers supported Major and Minor vers...REQ_DSC_BASE 20 The version shall be verified with the servers supported Major and Minor version of the DSC logic for compliancy. | customer-input/pdf/CVS154.pdf | CVS154 > Page 10 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 10 Document section CVS154 > Page 10 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-SYS-008 |
| REQ-AUTO-00870 | DSC_BASE_REQ 34 The length of the id field shall be verified.DSC_BASE_REQ 34 The length of the id field shall be verified. | customer-input/pdf/CVS154.pdf | CVS154 > Page 10 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 10 Document section CVS154 > Page 10 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ-AUTO-00871 | DSC_BASE_REQ 27 The hashAlgorithm shall be supported by the server.DSC_BASE_REQ 27 The hashAlgorithm shall be supported by the server. | customer-input/pdf/CVS154.pdf | CVS154 > Page 10 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 10 Document section CVS154 > Page 10 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00872 | Page 11 DSC_BASE_REQ 50 The length of every referenceHash shall be consistent with the output...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. | customer-input/pdf/CVS154.pdf | CVS154 > Page 11 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 11 Document section CVS154 > Page 11 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ-AUTO-00873 | DSC_BASE_INFO 35 The verification of servers support of specified dataRanges in the Verificat...DSC_BASE_INFO 35 The verification of servers support of specified dataRanges in the VerificationEntry, shall be stated for the DSC instance. | customer-input/pdf/CVS154.pdf | CVS154 > Page 11 | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm the exact ECU designation/variant and the agreed item definition and boundary used for the risk analysis (TARA). | OP-001 | None | OEM/Customer Review Interface | High | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 11 Document section CVS154 > Page 11 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-VV-001 |
| REQ-AUTO-00874 | DSC_BASE_REQ 28 The EncryptionEntry algorithm shall be supported by the server.DSC_BASE_REQ 28 The EncryptionEntry algorithm shall be supported by the server. | customer-input/pdf/CVS154.pdf | CVS154 > Page 11 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 11 Document section CVS154 > Page 11 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00875 | DSC_BASE_REQ 22 The length of key and iv shall be verified accordingly to the algorithm stipu...DSC_BASE_REQ 22 The length of key and iv shall be verified accordingly to the algorithm stipulated in EncryptionEntry. | customer-input/pdf/CVS154.pdf | CVS154 > Page 11 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | Key management | None | High | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 11 Document section CVS154 > Page 11 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Key management | Interface: None | SSR: SSR-KEY-001 |
| REQ-AUTO-00876 | DSC_BASE_INFO 36 The verification of servers support of specified dataRanges in the Encryptio...DSC_BASE_INFO 36 The verification of servers support of specified dataRanges in the EncryptionEntry, shall be stated for the DSC instance. | customer-input/pdf/CVS154.pdf | CVS154 > Page 11 | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm the exact ECU designation/variant and the agreed item definition and boundary used for the risk analysis (TARA). | OP-001 | None | OEM/Customer Review Interface | High | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 11 Document section CVS154 > Page 11 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-VV-001 |
| REQ-AUTO-00877 | DSC_BASE_REQ 48 If the DSC instance is rejected by the server (see Annex A) when transmitted...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. | customer-input/pdf/CVS154.pdf | CVS154 > Page 11 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 11 Document section CVS154 > Page 11 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00878 | The sequence tags for verificationEntries, encryptionEntries and itemEntries are required but...The sequence tags for verificationEntries, encryptionEntries and itemEntries are required but empty (zero length). | customer-input/pdf/CVS154.pdf | CVS154 > Page 14 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS154.pdf / page 14 Document section CVS154 > Page 14 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-VV-001 |
| REQ-AUTO-00879 | The User shall apply the latest version of this CVS31.The User shall apply the latest version of this CVS31. | customer-input/pdf/CVS31.pdf | CVS31 > Page 1 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 1 Document section CVS31 > Page 1 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ-AUTO-00880 | Internal Page 3 (31) Foreword This CVS31 contains requirement specification for TRATON GROUP...Internal Page 3 (31) Foreword This CVS31 contains requirement specification for TRATON GROUP and may be used by all within TRATON Group, if applicable. | customer-input/pdf/CVS31.pdf | CVS31 > Page 3 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 3 Document section CVS31 > Page 3 Supplier rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00881 | Any review of CVS31 shall only be done in agreement with the involved departments stated in t...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”. | customer-input/pdf/CVS31.pdf | CVS31 > Page 3 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 3 Document section CVS31 > Page 3 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-009 |
| REQ-AUTO-00882 | The whole standard has been reworked and shall be read in its entirety.The whole standard has been reworked and shall be read in its entirety. | customer-input/pdf/CVS31.pdf | CVS31 > Page 3 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 3 Document section CVS31 > Page 3 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ-AUTO-00883 | • Affiliate means any legal entity that directly or indirectly controls, is controlled by, or...• 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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 3 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 3 Document section CVS31 > Page 3 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00884 | Any deviations from this specification shall be documented and must be reviewed by the vehicl...Any deviations from this specification shall be documented and must be reviewed by the vehicle manufacturer. | customer-input/pdf/CVS31.pdf | CVS31 > Page 4 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 4 Document section CVS31 > Page 4 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-005 |
| REQ-AUTO-00885 | Shall be agreed between the supplier and the vehicle manufacturer.Shall be agreed between the supplier and the vehicle manufacturer. | customer-input/pdf/CVS31.pdf | CVS31 > Page 6 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | OEM/Customer Review Interface | Medium | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 6 Document section CVS31 > Page 6 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-SYS-005 |
| REQ-AUTO-00886 | It contains the information required for the server to verify the client’s subsequent request...It contains the information required for the server to verify the client’s subsequent request and to generate the corresponding response. | customer-input/pdf/CVS31.pdf | CVS31 > Page 6 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 6 Document section CVS31 > Page 6 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00887 | It contains the information required for the server to maintain continuous authenticated comm...It contains the information required for the server to maintain continuous authenticated communication with the client and to generate authenticated responses. | customer-input/pdf/CVS31.pdf | CVS31 > Page 6 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 6 Document section CVS31 > Page 6 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-003 |
| REQ-AUTO-00888 | AUTH_REQ 1 The server shall only support subfunctions in Table 4.AUTH_REQ 1 The server shall only support subfunctions in Table 4. | customer-input/pdf/CVS31.pdf | CVS31 > Page 7 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 7 Document section CVS31 > Page 7 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00889 | Table 4 – Supported subFunctions (ISO 14229-1:2020) Name verifyCertificateBidirectional proof...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 7 | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 7 Document section CVS31 > Page 7 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-KEY-003 |
| REQ-AUTO-00890 | If such an encapsulated 0x29 request is detected, the server shall return application-layer N...If such an encapsulated 0x29 request is detected, the server shall return application-layer NRC 0x39, provided as a correctly formatted SDT positive response. | customer-input/pdf/CVS31.pdf | CVS31 > Page 7 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 7 Document section CVS31 > Page 7 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-004 |
| REQ-AUTO-00891 | Internal Page 8 (31) 3.1 verifyCertificateBidirectional 3.1.1 Request AUTH_REQ 2 The request...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 8 | Accept with Assumption | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 8 Document section CVS31 > Page 8 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-KEY-004 |
| REQ-AUTO-00892 | Table 5 – verifyCertificateBidirectional Request Field Description Type/Value Cvt Included in...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 8 | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | Authentication | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 8 Document section CVS31 > Page 8 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Authentication | Interface: None | SSR: SSR-DAI-001 |
| REQ-AUTO-00893 | AUTH_REQ 118 If upon reception of verifyCertificateBidirectional request the Authentication d...AUTH_REQ 118 If upon reception of verifyCertificateBidirectional request the Authentication delay timer is expired, the server shall continue to process the verifyCertificateBidirectional request. | customer-input/pdf/CVS31.pdf | CVS31 > Page 8 | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier. | OP-003 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 8 Document section CVS31 > Page 8 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-KEY-005 |
| REQ-AUTO-00894 | AUTH_INFO 24 The column “Included in proofOfOwnershipServer”, present in several message-defi...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 8 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 8 Document section CVS31 > Page 8 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DAI-004 |
| REQ-AUTO-00895 | AUTH_REQ 45 If the server verifies the client certificate as valid, the server shall create t...AUTH_REQ 45 If the server verifies the client certificate as valid, the server shall create the requested client authentication pending state. | customer-input/pdf/CVS31.pdf | CVS31 > Page 8 | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier. | OP-003 | Authentication | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 8 Document section CVS31 > Page 8 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Authentication | Interface: None | SSR: SSR-DAI-001 |
| REQ-AUTO-00896 | Internal Page 9 (31) AUTH_REQ 119 If an authentication pending state already exists, the serv...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 9 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 9 Document section CVS31 > Page 9 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00897 | 3.1.1.1 challengeClient AUTH_REQ 3 This field shall consists of 32 octets.3.1.1.1 challengeClient AUTH_REQ 3 This field shall consists of 32 octets. | customer-input/pdf/CVS31.pdf | CVS31 > Page 9 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 9 Document section CVS31 > Page 9 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-005 |
| REQ-AUTO-00898 | AUTH_REQ 4 The challengeClient (ISO 14229-1:2020) shall be generated using a CRNG.AUTH_REQ 4 The challengeClient (ISO 14229-1:2020) shall be generated using a CRNG. | customer-input/pdf/CVS31.pdf | CVS31 > Page 9 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 9 Document section CVS31 > Page 9 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-009 |
| REQ-AUTO-00899 | 3.1.1.2 lengthOfCertificateClient AUTH_REQ 172 The expected range values of lengthOfCertifica...3.1.1.2 lengthOfCertificateClient AUTH_REQ 172 The expected range values of lengthOfCertificateClient shall be from 0x00C8 to 0x0800. | customer-input/pdf/CVS31.pdf | CVS31 > Page 9 | Accept with Assumption | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 9 Document section CVS31 > Page 9 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-KEY-004 |
| REQ-AUTO-00900 | AUTH_REQ 173 The server shall verify the value of lengthOfCertificateClient upon reception of...AUTH_REQ 173 The server shall verify the value of lengthOfCertificateClient upon reception of verifyCertificateBidirectional request. | customer-input/pdf/CVS31.pdf | CVS31 > Page 9 | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier. | OP-003 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 9 Document section CVS31 > Page 9 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-KEY-005 |
| REQ-AUTO-00901 | AUTH_REQ 174 If the lengthOfCertificateClient value is not within the expected range, the ser...AUTH_REQ 174 If the lengthOfCertificateClient value is not within the expected range, the server shall send negative response code 0x13 (incorrectMessageLengthOrInvalidFormat). | customer-input/pdf/CVS31.pdf | CVS31 > Page 9 | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier. | OP-003 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 9 Document section CVS31 > Page 9 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-KEY-005 |
| REQ-AUTO-00902 | 3.1.2 Response AUTH_REQ 5 The response for verifyCertificateBidirectional subfunction shall b...3.1.2 Response AUTH_REQ 5 The response for verifyCertificateBidirectional subfunction shall be formatted according to Table 6. | customer-input/pdf/CVS31.pdf | CVS31 > Page 9 | Accept with Assumption | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 9 Document section CVS31 > Page 9 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-KEY-004 |
| REQ-AUTO-00903 | AUTH_REQ 120 Upon positively responding, the server shall start the Authentication completion...AUTH_REQ 120 Upon positively responding, the server shall start the Authentication completion timer. | customer-input/pdf/CVS31.pdf | CVS31 > Page 9 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 9 Document section CVS31 > Page 9 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00904 | ephemeralPublicKeyServer See 3.1.2.3 uint8[] M Yes 3.1.2.1 challengeServer AUTH_REQ 6 The cha...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 10 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 10 Document section CVS31 > Page 10 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-SYS-006 |
| REQ-AUTO-00905 | AUTH_REQ 7 The proof/signature shall be generated according to the pseudo code below.AUTH_REQ 7 The proof/signature shall be generated according to the pseudo code below. | customer-input/pdf/CVS31.pdf | CVS31 > Page 11 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 11 Document section CVS31 > Page 11 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DAI-002 |
| REQ-AUTO-00906 | 3.1.3 Negative Response AUTH_REQ 121 If upon reception of verifyCertificateBidirectional requ...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 11 | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier. | OP-003 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 11 Document section CVS31 > Page 11 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-KEY-005 |
| REQ-AUTO-00907 | AUTH_REQ 122 If the server verifies the client certificate as invalid, it shall respond to th...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 11 | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier. | OP-003 | Authentication | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 11 Document section CVS31 > Page 11 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Authentication | Interface: None | SSR: SSR-DAI-001 |
| REQ-AUTO-00908 | AUTH_REQ 123 If the server fails or cannot determine that the authentication pending state wa...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 11 | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier. | OP-003 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 11 Document section CVS31 > Page 11 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-KEY-005 |
| REQ-AUTO-00909 | Internal Page 12 (31) 3.2.1 Request AUTH_REQ 8 The request for proofOfOwnership subfunction s...Internal Page 12 (31) 3.2.1 Request AUTH_REQ 8 The request for proofOfOwnership subfunction shall be defined according to Table 7. | customer-input/pdf/CVS31.pdf | CVS31 > Page 12 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 12 Document section CVS31 > Page 12 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-006 |
| REQ-AUTO-00910 | Table 7 – proofOfOwnership Request Field Description Type/Value Cvt Included in proofOfOwners...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 12 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 12 Document section CVS31 > Page 12 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-004 |
| REQ-AUTO-00911 | AUTH_REQ 111 If an existing authentication pending state is found, the server shall verify if...AUTH_REQ 111 If an existing authentication pending state is found, the server shall verify if the Authentication completion timer is currently running. | customer-input/pdf/CVS31.pdf | CVS31 > Page 12 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 12 Document section CVS31 > Page 12 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00912 | AUTH_REQ 112 If the Authentication completion timer is currently running, the server shall co...AUTH_REQ 112 If the Authentication completion timer is currently running, the server shall continue to process the client’s proofOfOwnership request. | customer-input/pdf/CVS31.pdf | CVS31 > Page 12 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 12 Document section CVS31 > Page 12 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00913 | AUTH_REQ 113 If the client proofOfOwnership signature verification fails, the server shall de...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 12 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | OEM/Customer Review Interface | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 12 Document section CVS31 > Page 12 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-DAI-004 |
| REQ-AUTO-00914 | AUTH_REQ 114 If the server fails or cannot determine that the authentication state was stored...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 12 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 12 Document section CVS31 > Page 12 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-003 |
| REQ-AUTO-00915 | AUTH_REQ 115 If the client’s proofOfOwnership signature is successfully verified, the server...AUTH_REQ 115 If the client’s proofOfOwnership signature is successfully verified, the server shall establish a new authentication state for the client. | customer-input/pdf/CVS31.pdf | CVS31 > Page 12 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 12 Document section CVS31 > Page 12 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DAI-004 |
| REQ-AUTO-00916 | Internal Page 13 (31) If an active authentication state already exists, the server shall repl...Internal Page 13 (31) If an active authentication state already exists, the server shall replace the existing state with the newly established one. | customer-input/pdf/CVS31.pdf | CVS31 > Page 13 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 13 Document section CVS31 > Page 13 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00917 | AUTH_REQ 160 The proofOfOwnershipClient shall be generated according to the pseudo code below.AUTH_REQ 160 The proofOfOwnershipClient shall be generated according to the pseudo code below. | customer-input/pdf/CVS31.pdf | CVS31 > Page 13 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 13 Document section CVS31 > Page 13 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-006 |
| REQ-AUTO-00918 | 3.2.2 Response AUTH_REQ 161 The response for proofOfOwnership subfunction shall be according...3.2.2 Response AUTH_REQ 161 The response for proofOfOwnership subfunction shall be according to Table 8. | customer-input/pdf/CVS31.pdf | CVS31 > Page 13 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 13 Document section CVS31 > Page 13 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-006 |
| REQ-AUTO-00919 | AUTH_REQ 162 The signature shall be generated according to the pseudo code below.AUTH_REQ 162 The signature shall be generated according to the pseudo code below. | customer-input/pdf/CVS31.pdf | CVS31 > Page 14 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 14 Document section CVS31 > Page 14 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DAI-002 |
| REQ-AUTO-00920 | 3.2.3 Negative Response AUTH_REQ 124 If the server determines that the client does not have a...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 14 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 14 Document section CVS31 > Page 14 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00921 | AUTH_REQ 125 If the server determines that the client have an existing authentication pending...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 14 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 14 Document section CVS31 > Page 14 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00922 | AUTH_REQ 126 If the server cannot determine if the client does have an existing authenticatio...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 14 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. | OP-004 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 14 Document section CVS31 > Page 14 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-003 |
| REQ-AUTO-00923 | AUTH_REQ 127 If the server is trying to delete the authentication pending state as consequenc...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 14 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | OEM/Customer Review Interface | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 14 Document section CVS31 > Page 14 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-DAI-004 |
| REQ-AUTO-00924 | AUTH_REQ 128 If the server is trying to delete the authentication pending state as consequenc...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 14 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. | OP-004 | None | OEM/Customer Review Interface | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 14 Document section CVS31 > Page 14 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-DAI-004 |
| REQ-AUTO-00925 | AUTH_REQ 129 If the server is deleting the authentication pending state as consequence of fai...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 14 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. | OP-004 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 14 Document section CVS31 > Page 14 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00926 | 3.3.1 Request AUTH_REQ 159 The request for deAuthenticate subfunction shall be formatted acco...3.3.1 Request AUTH_REQ 159 The request for deAuthenticate subfunction shall be formatted according to Table 9. | customer-input/pdf/CVS31.pdf | CVS31 > Page 15 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 15 Document section CVS31 > Page 15 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-006 |
| REQ-AUTO-00927 | Table 9 – deAuthenticate request message layout Field Description Type/Value Cvt Authenticati...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 15 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 15 Document section CVS31 > Page 15 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-RBAC-004 |
| REQ-AUTO-00928 | 0x00 – 0xFF M AUTH_REQ 158 The server shall delete/invalidate the client’s authentication pri...0x00 – 0xFF M AUTH_REQ 158 The server shall delete/invalidate the client’s authentication prior to positively responding to the deAuthenticate request. | customer-input/pdf/CVS31.pdf | CVS31 > Page 15 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 15 Document section CVS31 > Page 15 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00929 | 3.3.3 Negative Response AUTH_REQ 130 If the server determines that the client is not currentl...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 15 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 15 Document section CVS31 > Page 15 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00930 | AUTH_REQ 131 If the server cannot determine that the client is currently authenticated, it sh...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 15 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. | OP-004 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 15 Document section CVS31 > Page 15 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-003 |
| REQ-AUTO-00931 | Internal Page 16 (31) AUTH_REQ 132 If the server is unable to delete the client's authenticat...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 16 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. | OP-004 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 16 Document section CVS31 > Page 16 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-003 |
| REQ-AUTO-00932 | AUTH_INFO 133 If the server is unable to delete the client’s authentication state or cannot r...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 16 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 16 Document section CVS31 > Page 16 Supplier rationale Source classifies this as Non-functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00933 | 4 General 4.1 Certificate AUTH_REQ 175 The signature algorithm used throughout the authentica...4 General 4.1 Certificate AUTH_REQ 175 The signature algorithm used throughout the authentication process shall be ED25519. | customer-input/pdf/CVS31.pdf | CVS31 > Page 16 | Accept with Assumption | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm or correct the stated supplier assumption. | - | Authentication | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 16 Document section CVS31 > Page 16 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Authentication | Interface: None | SSR: SSR-DAI-001 |
| REQ-AUTO-00934 | AUTH_REQ 176 The client shall use the private key corresponding to the client certificate to...AUTH_REQ 176 The client shall use the private key corresponding to the client certificate to generate the signatures. | customer-input/pdf/CVS31.pdf | CVS31 > Page 16 | Accept with Assumption | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm or correct the stated supplier assumption. | - | Authentication | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 16 Document section CVS31 > Page 16 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Authentication | Interface: None | SSR: SSR-DAI-001 |
| REQ-AUTO-00935 | AUTH_REQ 177 The server shall use the private key corresponding to the server certificate to...AUTH_REQ 177 The server shall use the private key corresponding to the server certificate to generate the signatures. | customer-input/pdf/CVS31.pdf | CVS31 > Page 16 | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier. | OP-003 | Authentication | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 16 Document section CVS31 > Page 16 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Authentication | Interface: None | SSR: SSR-DAI-001 |
| REQ-AUTO-00936 | AUTH_REQ 163 The format and the structure of the certificates shall be based on (CVS30).AUTH_REQ 163 The format and the structure of the certificates shall be based on (CVS30). | customer-input/pdf/CVS31.pdf | CVS31 > Page 16 | Accept with Assumption | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 16 Document section CVS31 > Page 16 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-KEY-004 |
| REQ-AUTO-00937 | AUTH_REQ 164 The server shall reject a received client’s certificate, sent using the verifyCe...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 16 | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier. | OP-003 | Authentication | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 16 Document section CVS31 > Page 16 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Authentication | Interface: None | SSR: SSR-DAI-001 |
| REQ-AUTO-00938 | AUTH_INFO 7 It should not be possible to “unlock” the server using its own key/certificate.AUTH_INFO 7 It should not be possible to “unlock” the server using its own key/certificate. | customer-input/pdf/CVS31.pdf | CVS31 > Page 16 | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier. | OP-003 | Authentication | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 16 Document section CVS31 > Page 16 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Authentication | Interface: None | SSR: SSR-DAI-001 |
| REQ-AUTO-00939 | AUTH_REQ 165 The server shall verify the client certificate, sent using the verifyCertificate...AUTH_REQ 165 The server shall verify the client certificate, sent using the verifyCertificateBidirectional subFunction, according to Figure 3. | customer-input/pdf/CVS31.pdf | CVS31 > Page 16 | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier. | OP-003 | Authentication | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 16 Document section CVS31 > Page 16 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Authentication | Interface: None | SSR: SSR-DAI-001 |
| REQ-AUTO-00940 | AUTH_REQ 134 The server shall verify the Signature of the Client certificate using the AUTH-C...AUTH_REQ 134 The server shall verify the Signature of the Client certificate using the AUTH-CA EMP entity public key. | customer-input/pdf/CVS31.pdf | CVS31 > Page 16 | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier. | OP-003 | Authentication | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 16 Document section CVS31 > Page 16 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Authentication | Interface: None | SSR: SSR-DAI-001 |
| REQ-AUTO-00941 | Internal Page 18 (31) 4.1.1 NodeUID extension If the NodeUID extension is detected, the serve...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 18 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 18 Document section CVS31 > Page 18 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00942 | AUTH_REQ 9 • If the server NodeUID is not found in the NodeUID extension, the server shall re...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). | customer-input/pdf/CVS31.pdf | CVS31 > Page 18 | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier. | OP-003 | Authentication | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 18 Document section CVS31 > Page 18 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Authentication | Interface: None | SSR: SSR-DAI-001 |
| REQ-AUTO-00943 | AUTH_REQ 106 If the NodeUID extension is not detected, the operation shall continue as in AUT...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 18 | Accept with Assumption | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm or correct the stated supplier assumption. | - | Authentication | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 18 Document section CVS31 > Page 18 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Authentication | Interface: None | SSR: SSR-DAI-001 |
| REQ-AUTO-00944 | 4.1.2 ECU-Diagnostic Role extension AUTH_REQ 170 The ECU-Diagnostic role extension shall be i...4.1.2 ECU-Diagnostic Role extension AUTH_REQ 170 The ECU-Diagnostic role extension shall be included in the client certificate. | customer-input/pdf/CVS31.pdf | CVS31 > Page 18 | Accept with Assumption | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm or correct the stated supplier assumption. | - | Authentication | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 18 Document section CVS31 > Page 18 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Authentication | Interface: None | SSR: SSR-RBAC-002 |
| REQ-AUTO-00945 | AUTH_REQ 13 The roles shall correspond to a bit pattern-octet string.AUTH_REQ 13 The roles shall correspond to a bit pattern-octet string. | customer-input/pdf/CVS31.pdf | CVS31 > Page 18 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 18 Document section CVS31 > Page 18 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-006 |
| REQ-AUTO-00946 | AUTH_INFO 8 The interpretation of the roles should follow as the example below: • Role 1 -> 0...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 18 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 18 Document section CVS31 > Page 18 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-006 |
| REQ-AUTO-00947 | While the ECU-Diagnostic Role extension specifies the roles assigned to a client, the D-RBACC...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 18 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 18 Document section CVS31 > Page 18 Supplier rationale Source classifies this as Cybersecurity control (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00948 | AUTH_REQ 14 If D-RBACC extension is detected, the server shall overrule the RBACC with the D-...AUTH_REQ 14 If D-RBACC extension is detected, the server shall overrule the RBACC with the D-RBACC permissions. | customer-input/pdf/CVS31.pdf | CVS31 > Page 18 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 18 Document section CVS31 > Page 18 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00949 | AUTH_INFO 61 This means that if D-RBACC logic denies/permits certain access, the server shall...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 18 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 18 Document section CVS31 > Page 18 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-004 |
| REQ-AUTO-00950 | Internal Page 19 (31) As part of the certificate verification: AUTH_REQ 135 • The server shal...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 19 | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier. | OP-003 | Authentication | OEM/Customer Review Interface | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 19 Document section CVS31 > Page 19 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Authentication | Interface: OEM/Customer Review Interface | SSR: SSR-DAI-001 |
| REQ-AUTO-00951 | If content is invalid, the certificate is invalid and the server shall return a Negative Resp...If content is invalid, the certificate is invalid and the server shall return a Negative Response Code (NRC) 0x10, indicating generalReject. | customer-input/pdf/CVS31.pdf | CVS31 > Page 19 | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier. | OP-003 | Certificate handling | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 19 Document section CVS31 > Page 19 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Certificate handling | Interface: None | SSR: SSR-KEY-002 |
| REQ-AUTO-00952 | AUTH_REQ 136 • The server shall verify that the D-RBACC version provided by the client is com...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 19 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 19 Document section CVS31 > Page 19 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-003 |
| REQ-AUTO-00953 | If non-compliant, the certificate is invalid and the server shall return a Negative Response...If non-compliant, the certificate is invalid and the server shall return a Negative Response Code (NRC) 0x10, indicating generalReject. | customer-input/pdf/CVS31.pdf | CVS31 > Page 19 | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier. | OP-003 | Certificate handling | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 19 Document section CVS31 > Page 19 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Certificate handling | Interface: None | SSR: SSR-KEY-002 |
| REQ-AUTO-00954 | 4.1.4 basicContraints extension AUTH_REQ 42 The basicConstraints extension CA field shall be...4.1.4 basicContraints extension AUTH_REQ 42 The basicConstraints extension CA field shall be False. | customer-input/pdf/CVS31.pdf | CVS31 > Page 19 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 19 Document section CVS31 > Page 19 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-006 |
| REQ-AUTO-00955 | 4.1.5 Key Usage extension AUTH_REQ 15 The Key Usage extension (RFC 5280) shall be included in...4.1.5 Key Usage extension AUTH_REQ 15 The Key Usage extension (RFC 5280) shall be included in the client certificate. | customer-input/pdf/CVS31.pdf | CVS31 > Page 19 | Accept with Assumption | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm or correct the stated supplier assumption. | - | Authentication | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 19 Document section CVS31 > Page 19 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Authentication | Interface: None | SSR: SSR-DAI-001 |
| REQ-AUTO-00956 | AUTH_REQ 47 The Key Usage extension shall contain DigitalSignature.AUTH_REQ 47 The Key Usage extension shall contain DigitalSignature. | customer-input/pdf/CVS31.pdf | CVS31 > Page 19 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | Authentication | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 19 Document section CVS31 > Page 19 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Authentication | Interface: None | SSR: SSR-DAI-001 |
| REQ-AUTO-00957 | 4.1.6 Extended Key Usage extension AUTH_REQ 95 The Extended Key Usage extension (RFC 5280) sh...4.1.6 Extended Key Usage extension AUTH_REQ 95 The Extended Key Usage extension (RFC 5280) shall be included in the client certificate. | customer-input/pdf/CVS31.pdf | CVS31 > Page 19 | Accept with Assumption | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm or correct the stated supplier assumption. | - | Authentication | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 19 Document section CVS31 > Page 19 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Authentication | Interface: None | SSR: SSR-DAI-001 |
| REQ-AUTO-00958 | AUTH_REQ 107 The extension ExtendedKeyUsage shall contain clientAuth (1.3.6.1.5.5.7.3.2).AUTH_REQ 107 The extension ExtendedKeyUsage shall contain clientAuth (1.3.6.1.5.5.7.3.2). | customer-input/pdf/CVS31.pdf | CVS31 > Page 19 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 19 Document section CVS31 > Page 19 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-006 |
| REQ-AUTO-00959 | 4.1.7 SignatureAlgorithm AUTH_REQ 105 The extension SignatureAlgorithm shall contain ED25519...4.1.7 SignatureAlgorithm AUTH_REQ 105 The extension SignatureAlgorithm shall contain ED25519 (1.3.101.112). | customer-input/pdf/CVS31.pdf | CVS31 > Page 19 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 19 Document section CVS31 > Page 19 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-DAI-002 |
| REQ-AUTO-00960 | 4.1.8 Certificate Validity Time AUTH_REQ 169 The server shall validate the certificate so tha...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 19 | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier. | OP-003 | Authentication | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 19 Document section CVS31 > Page 19 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Authentication | Interface: None | SSR: SSR-DAI-001 |
| REQ-AUTO-00961 | Internal Page 20 (31) 4.2 State-keeping The server shall invalidate the authentication pendin...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). | customer-input/pdf/CVS31.pdf | CVS31 > Page 20 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 20 Document section CVS31 > Page 20 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00962 | AUTH_REQ 156 If a server reset is triggered by a client request (e.g., UDS service 0x11), the...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 20 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 20 Document section CVS31 > Page 20 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ-AUTO-00963 | If a client and server have successfully completed the authentication process, the server sha...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). | customer-input/pdf/CVS31.pdf | CVS31 > Page 20 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 20 Document section CVS31 > Page 20 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00964 | AUTH_REQ 157 If a server reset is triggered by a client request (e.g., UDS service 0x11), the...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 20 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 20 Document section CVS31 > Page 20 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-DIAG-004 |
| REQ-AUTO-00965 | The server’s authentication pending state shall contain the minimum of (non-exhaustive list):...The server’s authentication pending state shall contain the minimum of (non-exhaustive list): AUTH_REQ 140 • Client address that issued the authentication request. | customer-input/pdf/CVS31.pdf | CVS31 > Page 20 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 20 Document section CVS31 > Page 20 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00966 | The server’s authentication state shall contain the minimum of (non-exhaustive list): AUTH_RE...The server’s authentication state shall contain the minimum of (non-exhaustive list): AUTH_REQ 21 • SessionKey. | customer-input/pdf/CVS31.pdf | CVS31 > Page 21 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 21 Document section CVS31 > Page 21 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-TOOL-002 |
| REQ-AUTO-00967 | AUTH_REQ 147 • Client roles (ECU diagnostic Role extension in client’s certificate) AUTH_REQ...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 21 | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | Authentication | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 21 Document section CVS31 > Page 21 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Authentication | Interface: None | SSR: SSR-RBAC-002 |
| REQ-AUTO-00968 | AUTH_REQ 150 The server shall support only one authentication pending state.AUTH_REQ 150 The server shall support only one authentication pending state. | customer-input/pdf/CVS31.pdf | CVS31 > Page 21 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 21 Document section CVS31 > Page 21 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-TOOL-003 |
| REQ-AUTO-00969 | AUTH_REQ 167 The private keys shall be generated using a CRNG.AUTH_REQ 167 The private keys shall be generated using a CRNG. | customer-input/pdf/CVS31.pdf | CVS31 > Page 22 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 22 Document section CVS31 > Page 22 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-KEY-004 |
| REQ-AUTO-00970 | AUTH_REQ 168 The sessionKey shall be generated according to the pseudo code below.AUTH_REQ 168 The sessionKey shall be generated according to the pseudo code below. | customer-input/pdf/CVS31.pdf | CVS31 > Page 22 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 22 Document section CVS31 > Page 22 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-006 |
| REQ-AUTO-00971 | AUTH_REQ 24 The server shall ensure that the sessionKey is exclusively used for the applicati...AUTH_REQ 24 The server shall ensure that the sessionKey is exclusively used for the application responsible for communication over securedDataTransmission (CVS32). | customer-input/pdf/CVS31.pdf | CVS31 > Page 22 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the responsibility split and customer-owned part. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 22 Document section CVS31 > Page 22 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-SYS-008 |
| REQ-AUTO-00972 | 4.5 CRNG AUTH_REQ 33 Solution for a CRNG shall be according to (CVS150).4.5 CRNG AUTH_REQ 33 Solution for a CRNG shall be according to (CVS150). | customer-input/pdf/CVS31.pdf | CVS31 > Page 22 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 22 Document section CVS31 > Page 22 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-006 |
| REQ-AUTO-00973 | Internal Page 23 (31) 4.6 Role Based Access Control AUTH_REQ 25 The server shall always allow...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). | customer-input/pdf/CVS31.pdf | CVS31 > Page 23 | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 23 Document section CVS31 > Page 23 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-RBAC-004 |
| REQ-AUTO-00974 | AUTH_REQ 109 Only Passive time-based de-authentication shall be supported.AUTH_REQ 109 Only Passive time-based de-authentication shall be supported. | customer-input/pdf/CVS31.pdf | CVS31 > Page 23 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 23 Document section CVS31 > Page 23 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-006 |
| REQ-AUTO-00975 | 4.7.1 TimeBasedPassiveDeAuthentication AUTH_REQ 26 The server shall start the timer (A3) afte...4.7.1 TimeBasedPassiveDeAuthentication AUTH_REQ 26 The server shall start the timer (A3) after a valid proofOfOwnership has been received. | customer-input/pdf/CVS31.pdf | CVS31 > Page 23 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 23 Document section CVS31 > Page 23 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-TOOL-003 |
| REQ-AUTO-00976 | AUTH_REQ 27 The server shall restart the timer (A3) every time a request is received by the s...AUTH_REQ 27 The server shall restart the timer (A3) every time a request is received by the same client. | customer-input/pdf/CVS31.pdf | CVS31 > Page 23 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 23 Document section CVS31 > Page 23 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-003 |
| REQ-AUTO-00977 | AUTH_REQ 28 If the A3 timer timeouts before a new request is received (from the same client),...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 23 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 23 Document section CVS31 > Page 23 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-TOOL-003 |
| REQ-AUTO-00978 | AUTH_REQ 29 The parameter for passive timeout based deAuthenticate shall be decided in the pr...AUTH_REQ 29 The parameter for passive timeout based deAuthenticate shall be decided in the project. | customer-input/pdf/CVS31.pdf | CVS31 > Page 23 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 23 Document section CVS31 > Page 23 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-006 |
| REQ-AUTO-00979 | AUTH_INFO 14 The A3 timer differs from S3 timer in terms of expected behavior during timeout...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 23 | Needs Internal Review | Needs internal review. Confirm whether this should-level requirement is in the committed baseline. | No customer action until supplier review is complete. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 23 Document section CVS31 > Page 23 Supplier rationale Non-mandatory wording; baseline inclusion not yet confirmed. Implementation approach Decide baseline inclusion internally, then issue an Accept/Partial position. Acceptance condition Internal baseline decision recorded. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00980 | Internal Page 24 (31) 4.8 Authentication delay timer AUTH_INFO 38 The delay timer represents...Internal Page 24 (31) 4.8 Authentication delay timer AUTH_INFO 38 The delay timer represents the required minimum time between verifyCertificateBidirectional request attempts. | customer-input/pdf/CVS31.pdf | CVS31 > Page 24 | Accept with Assumption | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 24 Document section CVS31 > Page 24 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-KEY-004 |
| REQ-AUTO-00981 | AUTH_REQ 133 The delay timer shall be set to 1 second.AUTH_REQ 133 The delay timer shall be set to 1 second. | customer-input/pdf/CVS31.pdf | CVS31 > Page 24 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 24 Document section CVS31 > Page 24 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-006 |
| REQ-AUTO-00982 | AUTH_REQ 151 If the delay timer is not running, the server shall start it as part of verifyCe...AUTH_REQ 151 If the delay timer is not running, the server shall start it as part of verifyCertificateBidirectional request. | customer-input/pdf/CVS31.pdf | CVS31 > Page 24 | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier. | OP-003 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 24 Document section CVS31 > Page 24 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-KEY-005 |
| REQ-AUTO-00983 | AUTH_REQ 152 If the server can determine that a delay is not running after reset, it shall ac...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 24 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 24 Document section CVS31 > Page 24 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-003 |
| REQ-AUTO-00984 | AUTH_REQ 153 If the server cannot determine that a delay is not running after reset, it shall...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 24 | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Confirm the responsibility split and customer-owned part. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 24 Document section CVS31 > Page 24 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-003 |
| REQ-AUTO-00985 | AUTH_REQ 154 The Authentication completion timer shall be set to 1 minute.AUTH_REQ 154 The Authentication completion timer shall be set to 1 minute. | customer-input/pdf/CVS31.pdf | CVS31 > Page 24 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 24 Document section CVS31 > Page 24 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-006 |
| REQ-AUTO-00986 | Internal Page 29 (31) Annex B (informative) Change history Release Date Changes The whole sta...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. | customer-input/pdf/CVS31.pdf | CVS31 > Page 29 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS31.pdf / page 29 Document section CVS31 > Page 29 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-006 |
| REQ-AUTO-00987 | The User shall apply the latest version of this CVS32.The User shall apply the latest version of this CVS32. | customer-input/pdf/CVS32.pdf | CVS32 > Page 1 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 1 Document section CVS32 > Page 1 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-006 |
| REQ-AUTO-00988 | Internal Page 2 (29) Foreword This CVS32 contains requirement specification for TRATON GROUP...Internal Page 2 (29) Foreword This CVS32 contains requirement specification for TRATON GROUP and may be used by all within TRATON Group, if applicable. | customer-input/pdf/CVS32.pdf | CVS32 > Page 2 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 2 Document section CVS32 > Page 2 Supplier rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00989 | Any review of CVS32 shall only be done in agreement with the involved departments stated in t...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”. | customer-input/pdf/CVS32.pdf | CVS32 > Page 2 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 2 Document section CVS32 > Page 2 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-009 |
| REQ-AUTO-00990 | • Affiliate means any legal entity that directly or indirectly controls, is controlled by, or...• 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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 2 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 2 Document section CVS32 > Page 2 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-TOOL-003 |
| REQ-AUTO-00991 | The keywords “shall”, “should”, “must” and so forth are used in this document and are to be i...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]. | customer-input/pdf/CVS32.pdf | CVS32 > Page 4 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | Key management | None | High | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 4 Document section CVS32 > Page 4 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Key management | Interface: None | SSR: SSR-KEY-001 |
| REQ-AUTO-00992 | Internal Page 6 (29) 2 General SDT_REQ 1 The implementation of SDT (SecuredDataTransmission)...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]. | customer-input/pdf/CVS32.pdf | CVS32 > Page 6 | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm or correct the stated supplier assumption. | - | Diagnostic security | None | High | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 6 Document section CVS32 > Page 6 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Diagnostic security | Interface: None | SSR: SSR-RBAC-007 |
| REQ-AUTO-00993 | SDT_REQ 2 Whenever a requirement in this document deviates from requirements in ISO14229-1 [1...SDT_REQ 2 Whenever a requirement in this document deviates from requirements in ISO14229-1 [1] the requirements of this document shall take precedence. | customer-input/pdf/CVS32.pdf | CVS32 > Page 6 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 6 Document section CVS32 > Page 6 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-006 |
| REQ-AUTO-00994 | one diagnostic server in the boot-loader and one in the application, shall support SDT in all...one diagnostic server in the boot-loader and one in the application, shall support SDT in all execution states. | customer-input/pdf/CVS32.pdf | CVS32 > Page 6 | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | Diagnostic security | None | High | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 6 Document section CVS32 > Page 6 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Diagnostic security | Interface: None | SSR: SSR-RBAC-007 |
| REQ-AUTO-00995 | SDT_REQ 4 The SDT server shall use the diagnostic tester address of the SDT client to identif...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 6 | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | OP-002 | Authentication | None | High | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 6 Document section CVS32 > Page 6 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Authentication | Interface: None | SSR: SSR-RBAC-007 |
| REQ-AUTO-00996 | (There may be more than one authentication state).(There may be more than one authentication state). | customer-input/pdf/CVS32.pdf | CVS32 > Page 6 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 6 Document section CVS32 > Page 6 Supplier rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-00997 | SDT_REQ 5 The server shall not allow an SDT message with service 0x84 as the application laye...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). | customer-input/pdf/CVS32.pdf | CVS32 > Page 7 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 7 Document section CVS32 > Page 7 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-SYS-008 |
| REQ-AUTO-00998 | The server shall respond with application layer NRC 0x39, i.e.The server shall respond with application layer NRC 0x39, i.e. | customer-input/pdf/CVS32.pdf | CVS32 > Page 7 | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Confirm responsibility and implementation method. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 7 Document section CVS32 > Page 7 Supplier rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-008 |
| REQ-AUTO-00999 | the response shall be a properly formatted SDT positive 3 ISO 14299-1:2020 Clarifications and...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 7 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 7 Document section CVS32 > Page 7 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-01000 | SDT_REQ 6 Both client and server shall maintain instances of the state variables PREQARC and...SDT_REQ 6 Both client and server shall maintain instances of the state variables PREQARC and PRESARC. | customer-input/pdf/CVS32.pdf | CVS32 > Page 7 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 7 Document section CVS32 > Page 7 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-006 |
| REQ-AUTO-01001 | SDT_REQ 7 At construction of an SDT request, the client shall increment PREQARC by one (1) an...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 7 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 7 Document section CVS32 > Page 7 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-01002 | SDT_REQ 8 At reception of an SDT request, the server shall verify that the value of the ANTIR...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 7 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 7 Document section CVS32 > Page 7 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-006 |
| REQ-AUTO-01003 | SDT_REQ 9 At construction of an SDT response, the server shall increment PRESARC by one (1) a...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 7 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 7 Document section CVS32 > Page 7 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-006 |
| REQ-AUTO-01004 | SDT_REQ 10 At reception of an SDT response, the client shall verify that the value of the ANT...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 7 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | High | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 7 Document section CVS32 > Page 7 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-01005 | Internal Page 8 (29) SDT_REQ 11 The client should populate the ANTIREPLAYCNT protocol element...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 8 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Low | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 8 Document section CVS32 > Page 8 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-01006 | SDT_REQ 12 The server should populate the ANTIREPLAYCNT protocol element of the first respons...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 8 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 8 Document section CVS32 > Page 8 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-006 |
| REQ-AUTO-01007 | SDT_REQ 13 If either PREQARC or PRESARC reaches the maximum value 65535 (0xFFFF), the client...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 8 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 8 Document section CVS32 > Page 8 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-006 |
| REQ-AUTO-01008 | SDT_REQ 14 The client shall maintain the state variable PREQTAG.SDT_REQ 14 The client shall maintain the state variable PREQTAG. | customer-input/pdf/CVS32.pdf | CVS32 > Page 9 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 9 Document section CVS32 > Page 9 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-006 |
| REQ-AUTO-01009 | SDT_REQ 15 The CipherScheme used when constructing an SDT message shall be indicated by the S...SDT_REQ 15 The CipherScheme used when constructing an SDT message shall be indicated by the SIGENCRYPT protocol element according to Table 2. | customer-input/pdf/CVS32.pdf | CVS32 > Page 9 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 9 Document section CVS32 > Page 9 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-01010 | SDT_REQ 16 The CipherSchemes SDT_AEAD_CHACHA20_POLY1305 and SDT_POLY1305 shall be supported.SDT_REQ 16 The CipherSchemes SDT_AEAD_CHACHA20_POLY1305 and SDT_POLY1305 shall be supported. | customer-input/pdf/CVS32.pdf | CVS32 > Page 10 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 10 Document section CVS32 > Page 10 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-006 |
| REQ-AUTO-01011 | SDT_REQ 17 At SDT message reception, the recipient shall verify/decrypt the message using the...SDT_REQ 17 At SDT message reception, the recipient shall verify/decrypt the message using the CipherScheme indicated by the SIGENCRYPT protocol element. | customer-input/pdf/CVS32.pdf | CVS32 > Page 10 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 10 Document section CVS32 > Page 10 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-01012 | SDT_REQ 18 In case of a positive SDT response, the server shall respond to a client request w...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 10 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 10 Document section CVS32 > Page 10 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-006 |
| REQ-AUTO-01013 | SDT_REQ 19 The client may alter the CipherScheme between SDT requests within the same SDT seq...SDT_REQ 19 The client may alter the CipherScheme between SDT requests within the same SDT sequence. | customer-input/pdf/CVS32.pdf | CVS32 > Page 10 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 10 Document section CVS32 > Page 10 Supplier rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-01014 | SDT_REQ 20 Client and server should keep state variables that indicate which CipherScheme, an...SDT_REQ 20 Client and server should keep state variables that indicate which CipherScheme, and resulting key, was used in the previous SDT transaction. | customer-input/pdf/CVS32.pdf | CVS32 > Page 10 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | Key management | None | High | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 10 Document section CVS32 > Page 10 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Key management | Interface: None | SSR: SSR-KEY-006 |
| REQ-AUTO-01015 | SDT_REQ 21 At construction of an SDT request, if SIGENCRYPT is different from PSIGENCRYPT, th...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 10 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 10 Document section CVS32 > Page 10 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-006 |
| REQ-AUTO-01016 | SDT_REQ 22 At reception of an SDT request, if SIGENCRYPT is different from PSIGENCRYPT, the s...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 10 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | None | OEM/Customer Review Interface | High | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 10 Document section CVS32 > Page 10 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-VV-004 |
| REQ-AUTO-01017 | Client Server PREQARC = X PREQTAG=TAG_X PSIGENCRYPT=3 PKEY=p..p Check: ANTIREPLAYCNT > PREQAR...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]. | customer-input/pdf/CVS32.pdf | CVS32 > Page 11 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | Key management | None | High | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 11 Document section CVS32 > Page 11 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Key management | Interface: None | SSR: SSR-KEY-006 |
| REQ-AUTO-01018 | 𝐻𝐾𝐷𝐹(𝑖𝑘𝑚, 𝑠𝑎𝑙𝑡, 𝑖𝑛𝑓𝑜, 𝐿) → 𝑜𝑘𝑚 SDT_REQ 24 ikm : The ikm argument to the HKDF function shall b...𝐻𝐾𝐷𝐹(𝑖𝑘𝑚, 𝑠𝑎𝑙𝑡, 𝑖𝑛𝑓𝑜, 𝐿) → 𝑜𝑘𝑚 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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 11 | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 11 Document section CVS32 > Page 11 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-RBAC-004 |
| REQ-AUTO-01019 | SDT_REQ 25 salt: The salt argument to the HKDF function shall be set as the zero length octet...SDT_REQ 25 salt: The salt argument to the HKDF function shall be set as the zero length octet string (null). | customer-input/pdf/CVS32.pdf | CVS32 > Page 11 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 11 Document section CVS32 > Page 11 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-008 |
| REQ-AUTO-01020 | SDT_REQ 26 info: The info argument to the HKDF function shall be set as the concatenation of...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 11 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | None | High | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 11 Document section CVS32 > Page 11 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-008 |
| REQ-AUTO-01021 | SDT_REQ 27 The L argument to the HKDF function shall be set to 64.SDT_REQ 27 The L argument to the HKDF function shall be set to 64. | customer-input/pdf/CVS32.pdf | CVS32 > Page 12 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 12 Document section CVS32 > Page 12 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-008 |
| REQ-AUTO-01022 | SDT_REQ 28 Octets 0-31 of the okm shall be used as key by the client to encrypt, and the serv...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 12 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | Key management | None | High | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 12 Document section CVS32 > Page 12 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Key management | Interface: None | SSR: SSR-KEY-006 |
| REQ-AUTO-01023 | SDT_REQ 29 Octets 32-63 of the okm shall be used as key by the server to encrypt, and the cli...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 12 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | Key management | None | High | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 12 Document section CVS32 > Page 12 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Key management | Interface: None | SSR: SSR-KEY-006 |
| REQ-AUTO-01024 | Figure 5 – Use of HKDF output key material (okm) with SDT_CHACHA20_POLY1305 In subsequent sec...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 12 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | Key management | None | High | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 12 Document section CVS32 > Page 12 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Key management | Interface: None | SSR: SSR-KEY-006 |
| REQ-AUTO-01025 | SDT_REQ 31 𝑁: The 𝑁 shall be an octet string of length 12, constructed as follows: - the firs...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 12 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 12 Document section CVS32 > Page 12 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-006 |
| REQ-AUTO-01026 | SDT_REQ 32 𝑃: The 𝑃 (Plaintext) argument shall be the octet string that is the concatenation...SDT_REQ 32 𝑃: The 𝑃 (Plaintext) argument shall be the octet string that is the concatenation of the INTMSGREQID and SRVSPECPARAM. | customer-input/pdf/CVS32.pdf | CVS32 > Page 12 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 12 Document section CVS32 > Page 12 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-006 |
| REQ-AUTO-01027 | SDT_REQ 33 𝐶: When injected into, or extracted from an SDT message, the first octet of 𝐶 shal...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 12 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 12 Document section CVS32 > Page 12 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-01028 | Internal Page 13 (29) 3.2.2.1 Client Encryption/Decryption 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑒𝑛𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴,...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 13 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | Authentication | None | High | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 13 Document section CVS32 > Page 13 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Authentication | Interface: None | SSR: SSR-DAI-005 |
| REQ-AUTO-01029 | SDT_REQ 35 The client shall populate the APAR protocol element in the request so that bits 0,...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 13 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 13 Document section CVS32 > Page 13 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-01030 | SDT_REQ 36 The client shall populate the SIGLEN protocol element in the request with 16 (0x00...SDT_REQ 36 The client shall populate the SIGLEN protocol element in the request with 16 (0x0010). | customer-input/pdf/CVS32.pdf | CVS32 > Page 13 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 13 Document section CVS32 > Page 13 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-01031 | SDT_REQ 37 The client shall populate the SIGMACBYTE protocol element in the request with 𝑇𝐴𝐺.SDT_REQ 37 The client shall populate the SIGMACBYTE protocol element in the request with 𝑇𝐴𝐺. | customer-input/pdf/CVS32.pdf | CVS32 > Page 13 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 13 Document section CVS32 > Page 13 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-01032 | SDT_REQ 38 The client shall store 𝑇𝐴𝐺 in its state variable PREQTAG.SDT_REQ 38 The client shall store 𝑇𝐴𝐺 in its state variable PREQTAG. | customer-input/pdf/CVS32.pdf | CVS32 > Page 13 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 13 Document section CVS32 > Page 13 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-006 |
| REQ-AUTO-01033 | 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑑𝑒𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴, 𝐶, 𝑇𝐴𝐺) → 𝑜𝑘/𝑛𝑜𝑘, 𝑃 The client shall decrypt and verify the...𝐶𝐻𝐴𝐶𝐻𝐴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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 13 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 13 Document section CVS32 > Page 13 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-01034 | 3.2.2.2 Server Decryption/Encryption 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑑𝑒𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴, 𝐶, 𝑇𝐴𝐺) → 𝑜𝑘/𝑛𝑜𝑘, 𝑃 SD...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 13 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 13 Document section CVS32 > Page 13 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-006 |
| REQ-AUTO-01035 | 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑒𝑛𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴, 𝑃) → 𝐶, 𝑇𝐴𝐺 The server shall encrypt and authenticate the S...𝐶𝐻𝐴𝐶𝐻𝐴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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 13 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | Authentication | None | High | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 13 Document section CVS32 > Page 13 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Authentication | Interface: None | SSR: SSR-DAI-005 |
| REQ-AUTO-01036 | SDT_REQ 46 The server shall populate the APAR protocol element in the response so that bits 4...SDT_REQ 46 The server shall populate the APAR protocol element in the response so that bits 4 and 5 are set to true. | customer-input/pdf/CVS32.pdf | CVS32 > Page 13 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 13 Document section CVS32 > Page 13 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-006 |
| REQ-AUTO-01037 | Internal Page 14 (29) SDT_REQ 47 The server shall populate the SIGLEN protocol element in the...Internal Page 14 (29) SDT_REQ 47 The server shall populate the SIGLEN protocol element in the request with 16 (0x0010). | customer-input/pdf/CVS32.pdf | CVS32 > Page 14 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 14 Document section CVS32 > Page 14 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-006 |
| REQ-AUTO-01038 | SDT_REQ 48 The server shall populate the SIGMACBYTE protocol element in the request with 𝑇𝐴𝐺.SDT_REQ 48 The server shall populate the SIGMACBYTE protocol element in the request with 𝑇𝐴𝐺. | customer-input/pdf/CVS32.pdf | CVS32 > Page 14 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 14 Document section CVS32 > Page 14 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-006 |
| REQ-AUTO-01039 | one octet, and the rest should go in the SRVSPECPARAM protocol element.one octet, and the rest should go in the SRVSPECPARAM protocol element. | customer-input/pdf/CVS32.pdf | CVS32 > Page 14 | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Low | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 14 Document section CVS32 > Page 14 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-01040 | SDT_REQ 49 The L argument to the HKDF function shall be set to 64.SDT_REQ 49 The L argument to the HKDF function shall be set to 64. | customer-input/pdf/CVS32.pdf | CVS32 > Page 15 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 15 Document section CVS32 > Page 15 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-008 |
| REQ-AUTO-01041 | SDT_REQ 50 Octets 0-31 of the okm shall be used as key by the client to authenticate, and the...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 15 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | Authentication | None | High | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 15 Document section CVS32 > Page 15 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Authentication | Interface: None | SSR: SSR-DAI-005 |
| REQ-AUTO-01042 | SDT_REQ 51 Octets 32-63 of the okm shall be used as key by the server to authenticate, and th...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 15 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | Authentication | None | High | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 15 Document section CVS32 > Page 15 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Authentication | Interface: None | SSR: SSR-DAI-005 |
| REQ-AUTO-01043 | Figure 7 – Use of HKDF output key material (okm) with SDT_POLY1305 In subsequent sections (3....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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 15 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | Key management | None | High | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 15 Document section CVS32 > Page 15 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Key management | Interface: None | SSR: SSR-KEY-006 |
| REQ-AUTO-01044 | SDT_REQ 91 𝑁: The 𝑁 shall be an octet string of length 12, constructed as follows: - the firs...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 15 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 15 Document section CVS32 > Page 15 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-006 |
| REQ-AUTO-01045 | Internal Page 16 (29) 3.2.3.1 Client Authentication/Verification 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑎𝑢𝑡ℎ𝑒𝑛𝑡𝑖𝑐𝑎𝑡...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 16 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces; OEM/Customer Review Interface | High | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 16 Document section CVS32 > Page 16 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces; OEM/Customer Review Interface | SSR: SSR-VV-005 |
| REQ-AUTO-01046 | SDT_REQ 55 The client shall populate the APAR protocol element in the request so that bits 0,...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 16 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 16 Document section CVS32 > Page 16 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-01047 | SDT_REQ 56 The client shall populate the SIGLEN protocol element in the request with 16 (0x00...SDT_REQ 56 The client shall populate the SIGLEN protocol element in the request with 16 (0x0010). | customer-input/pdf/CVS32.pdf | CVS32 > Page 16 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 16 Document section CVS32 > Page 16 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-01048 | SDT_REQ 57 The client shall populate the SIGMACBYTE protocol element in the request with 𝑇𝐴𝐺.SDT_REQ 57 The client shall populate the SIGMACBYTE protocol element in the request with 𝑇𝐴𝐺. | customer-input/pdf/CVS32.pdf | CVS32 > Page 16 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 16 Document section CVS32 > Page 16 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-01049 | SDT_REQ 58 The client shall store 𝑇𝐴𝐺 in its state variable PREQTAG.SDT_REQ 58 The client shall store 𝑇𝐴𝐺 in its state variable PREQTAG. | customer-input/pdf/CVS32.pdf | CVS32 > Page 16 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 16 Document section CVS32 > Page 16 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-006 |
| REQ-AUTO-01050 | 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑣𝑒𝑟𝑖𝑓𝑦(𝐾, 𝑁, 𝐴, 𝐶𝑛𝑢𝑙𝑙, 𝑇𝐴𝐺) → ok/nok,𝑃𝑛𝑢𝑙𝑙 SDT_REQ 59 The client shall verif...𝐶𝐻𝐴𝐶𝐻𝐴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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 16 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 16 Document section CVS32 > Page 16 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-01051 | 3.2.3.2 Server Verification/Authentication 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑣𝑒𝑟𝑖𝑓𝑦(𝐾, 𝑁, 𝐴, 𝐶𝑛𝑢𝑙𝑙, 𝑇𝐴𝐺) → ok/...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 16 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | None | OEM/Customer Review Interface | High | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 16 Document section CVS32 > Page 16 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: OEM/Customer Review Interface | SSR: SSR-VV-004 |
| REQ-AUTO-01052 | 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑎𝑢𝑡ℎ𝑒𝑛𝑡𝑖𝑐𝑎𝑡𝑒(𝐾, 𝑁, 𝐴, 𝑃𝑛𝑢𝑙𝑙) → 𝐶𝑛𝑢𝑙𝑙, 𝑇𝐴𝐺 SDT_REQ 63 The server shall authen...𝐶𝐻𝐴𝐶𝐻𝐴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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 16 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 16 Document section CVS32 > Page 16 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-006 |
| REQ-AUTO-01053 | Internal Page 17 (29) SDT_REQ 64 The server shall populate the APAR protocol element in the r...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 17 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 17 Document section CVS32 > Page 17 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-006 |
| REQ-AUTO-01054 | SDT_REQ 65 The server shall populate the SIGLEN protocol element in the response with 16 (0x0...SDT_REQ 65 The server shall populate the SIGLEN protocol element in the response with 16 (0x0010). | customer-input/pdf/CVS32.pdf | CVS32 > Page 17 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 17 Document section CVS32 > Page 17 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-006 |
| REQ-AUTO-01055 | SDT_REQ 66 The client shall populate the SIGMACBYTE protocol element in the response with 𝑇𝐴𝐺.SDT_REQ 66 The client shall populate the SIGMACBYTE protocol element in the response with 𝑇𝐴𝐺. | customer-input/pdf/CVS32.pdf | CVS32 > Page 17 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | External Interfaces | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 17 Document section CVS32 > Page 17 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: External Interfaces | SSR: SSR-COM-002 |
| REQ-AUTO-01056 | The SDT positive response may of course contain an encapsulated negative UDS response.The SDT positive response may of course contain an encapsulated negative UDS response. | customer-input/pdf/CVS32.pdf | CVS32 > Page 18 | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Confirm whether this is binding or context only. | - | None | None | Low | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 18 Document section CVS32 > Page 18 Supplier rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Responsibility assumption Supplier (record only) Traceability Capability: None | Interface: None | SSR: None |
| REQ-AUTO-01057 | SDT_REQ 67 Other than the NRCs 0x3A, 0x13 and 0x21, specified by ISO14229-1:2020 [1], the ser...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”. | customer-input/pdf/CVS32.pdf | CVS32 > Page 18 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 18 Document section CVS32 > Page 18 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-006 |
| REQ-AUTO-01058 | Internal Page 19 (29) Figure 10 – Server's error and state handling SDT_REQ 68 At reception o...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 19 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | Secure communication | None | High | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 19 Document section CVS32 > Page 19 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Secure communication | Interface: None | SSR: SSR-COM-008 |
| REQ-AUTO-01059 | SDT_REQ 69 At reception of an SDT request, if the requesting client is unauthenticated, the s...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 19 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 19 Document section CVS32 > Page 19 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-006 |
| REQ-AUTO-01060 | Internal Page 20 (29) SDT_REQ 70 At reception of an SDT request, if the request is too short...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 20 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 20 Document section CVS32 > Page 20 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-006 |
| REQ-AUTO-01061 | SDT_REQ 71 At reception of an SDT request, if ANTIREPLAYCNT ≤ PREQARC, the server shall respo...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 20 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 20 Document section CVS32 > Page 20 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-006 |
| REQ-AUTO-01062 | SDT_REQ 88 At reception of an SDT request, if PRESARC is exhausted, the server shall respond...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 20 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 20 Document section CVS32 > Page 20 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-006 |
| REQ-AUTO-01063 | SDT_REQ 72 At reception of an SDT request, if SIGENCRYPT is not supported, the server shall r...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 20 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 20 Document section CVS32 > Page 20 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-006 |
| REQ-AUTO-01064 | SDT_REQ 73 At reception of an SDT request, if APAR is in conflict with SIGENCRYPT, the server...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 20 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 20 Document section CVS32 > Page 20 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-006 |
| REQ-AUTO-01065 | SDT_REQ 74 At reception of an SDT request, if SIGLEN is in conflict with SIGENCRYPT, the serv...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 20 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 20 Document section CVS32 > Page 20 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-006 |
| REQ-AUTO-01066 | SDT_REQ 75 At reception of an SDT request, if the server fails to verify/decrypt the request,...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 20 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 20 Document section CVS32 > Page 20 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-006 |
| REQ-AUTO-01067 | SDT_REQ 76 The server shall update its state, (set PREQARC to the value received in the ANTIR...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 20 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 20 Document section CVS32 > Page 20 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-006 |
| REQ-AUTO-01068 | SDT_REQ 77 The server shall update its state, (increment PRESARC by one (1)), if and only if...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”). | customer-input/pdf/CVS32.pdf | CVS32 > Page 20 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | Authentication | None | High | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 20 Document section CVS32 > Page 20 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: Authentication | Interface: None | SSR: SSR-DAI-005 |
| REQ-AUTO-01069 | SDT_REQ 78 The client shall update its state, (increment PREQARC by one (1), if and only if i...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”). | customer-input/pdf/CVS32.pdf | CVS32 > Page 21 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | Authentication | None | High | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 21 Document section CVS32 > Page 21 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: Authentication | Interface: None | SSR: SSR-DAI-005 |
| REQ-AUTO-01070 | Internal Page 22 (29) Figure 12 – The client's error and state handling SDT_REQ 79 At recepti...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 22 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 22 Document section CVS32 > Page 22 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-006 |
| REQ-AUTO-01071 | SDT_REQ 81 At reception of an SDT response, if ANTIREPLAYCNT ≤ PRESARC, the client shall disc...SDT_REQ 81 At reception of an SDT response, if ANTIREPLAYCNT ≤ PRESARC, the client shall discard the | customer-input/pdf/CVS32.pdf | CVS32 > Page 22 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 22 Document section CVS32 > Page 22 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-006 |
| REQ-AUTO-01072 | Internal Page 23 (29) SDT_REQ 82 At reception of an SDT response, if SIGENCRYPT is not suppor...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 23 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 23 Document section CVS32 > Page 23 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-006 |
| REQ-AUTO-01073 | SDT_REQ 84 At reception of an SDT response, if SIGLEN is in conflict with SIGENCRYPT, the cli...SDT_REQ 84 At reception of an SDT response, if SIGLEN is in conflict with SIGENCRYPT, the client shall discard the response. | customer-input/pdf/CVS32.pdf | CVS32 > Page 23 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 23 Document section CVS32 > Page 23 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-006 |
| REQ-AUTO-01074 | SDT_REQ 85 At reception of an SDT response, if the client fails to verify/decrypt the respons...SDT_REQ 85 At reception of an SDT response, if the client fails to verify/decrypt the response, the client shall discard the response. | customer-input/pdf/CVS32.pdf | CVS32 > Page 23 | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm or correct the stated supplier assumption. | - | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 23 Document section CVS32 > Page 23 Supplier rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Responsibility assumption Supplier Cybersecurity Engineering Traceability Capability: None | Interface: None | SSR: SSR-SYS-006 |
| REQ-AUTO-01075 | SDT_REQ 86 The client shall update its state, (set PRESARC to the value received in the ANTIR...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”). | customer-input/pdf/CVS32.pdf | CVS32 > Page 23 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | None | None | High | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 23 Document section CVS32 > Page 23 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-006 |
| REQ-AUTO-01076 | SDT_REQ 87 If the client determines an SDT request to be lost in transit, or, if it receives...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. | customer-input/pdf/CVS32.pdf | CVS32 > Page 23 | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | OP-005 | None | None | Medium | Pending | DetailsSource customer-input/pdf/CVS32.pdf / page 23 Document section CVS32 > Page 23 Supplier rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Responsibility assumption Shared (OEM / Supplier) Traceability Capability: None | Interface: None | SSR: SSR-COM-006 |