Customer Requirements
Customer asks, source evidence, assumptions, proposed solution, implementation notes, risks, and ambiguity flags.
Customer Requirements
Customer asks, source evidence, assumptions, proposed solution, implementation notes, risks, and ambiguity flags.
Customer Requirement Decision Impact
Downstream engineering artifacts remain provisional until customer clarification closure evidence is complete.
Search and Filters
Customer Requirement Analysis
This table is horizontally scrollable. Use the bottom scrollbar to view all columns.
| Requirement ID | Original Statement | Source Document | Category | Pre-Analysis | Proposed Solution | Proposed Implementation | Decision Control | Ambiguity / Risk | Details |
|---|---|---|---|---|---|---|---|---|---|
| 1.1 RFQX: RFQX-1001379436-P10-000-01-0001 | This document contains general cybersecurity requirements. The requirements specified in this document are applicable to all ECUs. The supplier of ECU is responsible to take all the necessary measures and steps to comply with the requirements listed in this document. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Cybersecurity | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 3 / page 3 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 1.2 RFQX: RFQX-1001379436-P10-000-01-0002 | The target readers of this specification are ECU suppliers, which can be either internal or external in relation to the vehicle manufacturer. In both cases, whenever the term “ECU supplier” or just “supplier” is used in this specification it refers to the company and organization which is responsible for the implementation and delivery of the ECU according to the requirements in this specification. And in both cases, whenever the term “vehicle manufacturer” is used in this specification this term refers to the system owner (responsible receiver) at the vehicle manufacturer. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Hardware | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 3 / page 3 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 1.3 RFQX: RFQX-1001379436-P10-000-01-0003 | Term Definition Shall This word, or the term "Required", means that the definition is an absolute requirement of the specification. Threat Analysis and Risk Assessment A structured approach to identify possible threats and evaluate risks with respect to the potential damages and the effort needed for successful attack. Cybersecurity concept A cybersecurity concept is a work product that documents cybersecurity relevant aspects of the product. 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. Table 1: Definition of terms | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Cybersecurity | Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Needs internal review. Confirm the extracted wording and the intended scope before committing a supplier position. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Re-read the Source document, confirm intent, then re-issue an Accept/Partial position. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 3 / page 3 Pre-analysis Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Assumptions Internal review confirms wording and scope. Engineering notes Complete internal review of wording and baseline scope. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| 1.4 RFQX: RFQX-1001379436-P10-000-01-0004 | Abbreviation Description ECU Electronic Control Unit Table 2: Abbreviated terms | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Hardware | Source classifies this as Unknown (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 3 / page 3 Pre-analysis Source classifies this as Unknown (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No supplier action - document reference / boilerplate. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-1001379436-P10-000-01-0005 RFQX: RFQX-1001379436-P10-000-01-0005 | 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. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Cybersecurity | Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 3 / page 3 Pre-analysis Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes No supplier action - document reference / boilerplate. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| INFO_SEC_001 RFQX: RFQX-1001379436-P10-000-01-0006 | Cybersecurity principles are high level requirements that drive development and refinement of functional and technical cybersecurity requirements. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Cybersecurity | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page General cybersecurity requirements / page 5 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_SEC_0001 RFQX: RFQX-1001379436-P10-000-01-0007 | The supplier shall provide documentation describing their strategies and methods for working with embedded systems cybersecurity. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Cybersecurity | Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page Cybersecurity methods and strategies / page 5 Pre-analysis Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| REQ_SEC_0002 RFQX: RFQX-1001379436-P10-000-01-0008 | The supplier shall perform risk assessment based on a threat and vulnerability analysis for each release, including any vehicle manufacturer-specific adaptations. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Cybersecurity | Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page Risk assessment / page 5 Pre-analysis Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| RFQX-1001379436-P10-000-01-0009 RFQX: RFQX-1001379436-P10-000-01-0009 | Method and scope shall be proposed to and approved by the vehicle manufacturer. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 5 / page 5 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-1001379436-P10-000-01-0010 RFQX: RFQX-1001379436-P10-000-01-0010 | Documentation on the method and results shall be provided to the vehicle manufacturer. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | System | Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 5 / page 5 Pre-analysis Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-1001379436-P10-000-01-0011 RFQX: RFQX-1001379436-P10-000-01-0011 | Note: The vehicle manufacturer and supplier shall collaboratively define the context of the system or function to enable the supplier performing the risk assessment. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Software | Low extraction confidence or flagged for human review. | Needs internal review. Confirm the extracted wording and the intended scope before committing a supplier position. | Re-read the Source document, confirm intent, then re-issue an Accept/Partial position. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 5 / page 5 Pre-analysis Low extraction confidence or flagged for human review. Assumptions Internal review confirms wording and scope. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| REQ_SEC_0003 RFQX: RFQX-1001379436-P10-000-01-0012 | The supplier shall describe the cybersecurity concept and how it is implemented in hardware and software respectively. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Cybersecurity | Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page Cybersecurity concept / page 5 Pre-analysis Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| REQ_SEC_0022 RFQX: RFQX-1001379436-P10-000-01-0013 | All risks identified in cybersecurity risk analyses shall be evaluated. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Cybersecurity | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page Marcus Lindner EPXC Published 6(16) / page 6 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| RFQX-1001379436-P10-000-01-0014 RFQX: RFQX-1001379436-P10-000-01-0014 | For each risk identified in the cybersecurity risk analyses, a risk treatment decision shall be made to avoid, reduce, share, or retain the risk. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Cybersecurity | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 / page 6 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| REQ_SEC_0023 RFQX: RFQX-1001379436-P10-000-01-0015 | Cybersecurity controls shall sufficiently reduce the risk. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Cybersecurity | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 / page 6 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| RFQX-1001379436-P10-000-01-0016 RFQX: RFQX-1001379436-P10-000-01-0016 | It shall be possible to verify which cybersecurity controls were derived from which requirements. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Cybersecurity | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 / page 6 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| REQ_SEC_0024 RFQX: RFQX-1001379436-P10-000-01-0017 | The cybersecurity concept of the supplier shall contain a documentation of the accepted residual risk and be agreed with the vehicle manufacturer. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Cybersecurity | Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 / page 6 Pre-analysis Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| REQ_SEC_0004 RFQX: RFQX-1001379436-P10-000-01-0018 | The supplier shall provide documentation of the verification and validation methods of cybersecurity features. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Cybersecurity | Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page Verification and validation / page 6 Pre-analysis Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| REQ_SEC_0005 RFQX: RFQX-1001379436-P10-000-01-0019 | The supplier shall provide test reports detailing the results from the verification and validation of cybersecurity features. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Cybersecurity | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 / page 6 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| REQ_SEC_0040 RFQX: RFQX-1001379436-P10-000-01-0020 | The vehicle manufacturer reserves the right to perform penetration testing on the ECU to identify potential vulnerabilities. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Hardware | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 / page 6 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_SEC_0007 RFQX: RFQX-1001379436-P10-000-01-0021 | An inventory of software and protocols, including their versions, shall be provided by the supplier. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page Documentation / page 6 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_SEC_0025 RFQX: RFQX-1001379436-P10-000-01-0022 | A BOM containing part numbers and versions of hardware components used in the product shall be provided by the supplier. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Hardware | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page Marcus Lindner EPXC Published 7(16) / page 7 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_SEC_0041 RFQX: RFQX-1001379436-P10-000-01-0023 | 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. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Process / compliance | Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 7 / page 7 Pre-analysis Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_SEC_0042 RFQX: RFQX-1001379436-P10-000-01-0024 | The vehicle manufacturer and the supplier shall set up a cybersecurity DIA to agree on the responsibilities for the distributed cybersecurity activities. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Cybersecurity | Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 7 / page 7 Pre-analysis Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| REQ_SEC_0008 RFQX: RFQX-1001379436-P10-000-01-0025 | The ECU shall be able to verify integrity and authenticity of a vehicle manufacturer-specified set of data stored within the ECU. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Cybersecurity | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page Software security / page 7 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| RFQX-1001379436-P10-000-01-0026 RFQX: RFQX-1001379436-P10-000-01-0026 | Methods shall be proposed to and approved by the vehicle manufacturer. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 7 / page 7 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| REQ_SEC_0009 RFQX: RFQX-1001379436-P10-000-01-0027 | The supplier shall apply methods for isolation of software/hardware components and data to reduce the effect in case of a cybersecurity breach. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Cybersecurity | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page Security architecture / page 7 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| REQ_SEC_0020 RFQX: RFQX-1001379436-P10-000-01-0028 | Selection of cryptographic methods and their use shall be agreed upon between the vehicle manufacturer and the supplier. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page Cryptographic libraries / page 7 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_SEC_0010 RFQX: RFQX-1001379436-P10-000-01-0029 | All network services implemented in the ECU shall undergo hardening. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Hardware | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page Services / page 8 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_SEC_0011 RFQX: RFQX-1001379436-P10-000-01-0030 | The ECU shall only expose network and communication services that have been agreed upon with the vehicle manufacturer. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Hardware | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 / page 8 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_SEC_0012 RFQX: RFQX-1001379436-P10-000-01-0031 | Communication interfaces shall use boundary controls such as ingress/egress filtering. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | System | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page Interfaces / page 8 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_SEC_0013 RFQX: RFQX-1001379436-P10-000-01-0032 | Communication boundary controls shall be configurable by the vehicle manufacturer. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | System | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 / page 8 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-1001379436-P10-000-01-0033 RFQX: RFQX-1001379436-P10-000-01-0033 | Methods shall be proposed and approved by the vehicle manufacturer. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 / page 8 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| REQ_SEC_0014 RFQX: RFQX-1001379436-P10-000-01-0034 | Any interfaces used for development purposes shall be removed or disabled in series production. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | System | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 / page 8 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-1001379436-P10-000-01-0035 RFQX: RFQX-1001379436-P10-000-01-0035 | The details shall be agreed upon between the vehicle manufacturer and the supplier. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 / page 8 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| REQ_SEC_0026 RFQX: RFQX-1001379436-P10-000-01-0036 | Only hardware interfaces and protocols specified by the vehicle manufacturer shall be available in series production. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Hardware | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 / page 8 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_SEC_0027 RFQX: RFQX-1001379436-P10-000-01-0037 | 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. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Cybersecurity | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page Information security / page 8 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| REQ_SEC_0028 RFQX: RFQX-1001379436-P10-000-01-0038 | Data specified by the vehicle manufacturer shall be protected from manipulations. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page Marcus Lindner EPXC Published 9(16) / page 9 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| REQ_SEC_0029 RFQX: RFQX-1001379436-P10-000-01-0039 | Data specified by the vehicle manufacturer shall be protected from disclosure. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 9 / page 9 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| REQ_SEC_0006 RFQX: RFQX-1001379436-P10-000-01-0040 | Intellectual property of the vehicle manufacturer shall be protected from disclosure. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 9 / page 9 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| REQ_SEC_0016 RFQX: RFQX-1001379436-P10-000-01-0041 | 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. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page Key management / page 9 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_SEC_0019 RFQX: RFQX-1001379436-P10-000-01-0042 | Secrets, public keys and other data used for cybersecurity controls in production vehicle systems shall be different from those used in pre-production phases. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 9 / page 9 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| REQ_SEC_0021 RFQX: RFQX-1001379436-P10-000-01-0043 | ECUs shall only contain the secrets agreed between the vehicle manufacturer and the supplier. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 9 / page 9 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_SEC_0015 RFQX: RFQX-1001379436-P10-000-01-0044 | ECUs shall conform to the harmonized Security Access specification [1] provided by the vehicle manufacturer. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Cybersecurity | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 9 / page 9 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| REQ_SEC_0043 RFQX: RFQX-1001379436-P10-000-01-0045 | It shall be possible to update the software of the ECU. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Cybersecurity | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page Security updates / page 9 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| REQ_SEC_0030 RFQX: RFQX-1001379436-P10-000-01-0046 | The supplier shall inform the vehicle manufacturer if any cybersecurity patches are available. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Cybersecurity | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page Marcus Lindner EPXC Published 10(16) / page 10 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| REQ_SEC_0044 RFQX: RFQX-1001379436-P10-000-01-0047 | An incident response process shall be proposed to and approved by the vehicle manufacturer. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Process / compliance | Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page Incident management / page 10 Pre-analysis Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_SEC_0045 RFQX: RFQX-1001379436-P10-000-01-0048 | In case of cybersecurity incidents, the incident response process shall be used. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Cybersecurity | Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 / page 10 Pre-analysis Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| REQ_SEC_0046 RFQX: RFQX-1001379436-P10-000-01-0049 | The incident response process shall be maintained for the entire product lifetime. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Process / compliance | Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 / page 10 Pre-analysis Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_SEC_0032 RFQX: RFQX-1001379436-P10-000-01-0050 | The incident response process shall ensure that risk is managed in coordination with the vehicle manufacturer. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Process / compliance | Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 / page 10 Pre-analysis Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_SEC_0033 RFQX: RFQX-1001379436-P10-000-01-0051 | Any vulnerabilities that are identified during product lifecycle shall be promptly communicated to the vehicle manufacturer. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page Vulnerability management / page 10 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-1001379436-P10-000-01-0052 RFQX: RFQX-1001379436-P10-000-01-0052 | The report shall include information needed to identify the affected vehicles/products. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 / page 10 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-1001379436-P10-000-01-0053 RFQX: RFQX-1001379436-P10-000-01-0053 | Methods including the stipulation of a reasonable notification time shall be proposed to and approved by the vehicle manufacturer. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 / page 10 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| REQ_SEC_0034 RFQX: RFQX-1001379436-P10-000-01-0054 | Following each identified and reported vulnerability, the supplier and vehicle manufacturer shall agree on an initial response to the vulnerability. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | System | Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 / page 10 Pre-analysis Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_SEC_0035 RFQX: RFQX-1001379436-P10-000-01-0055 | Within adequate time after the initial vulnerability report, the supplier shall provide more information about the identified vulnerability. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | System | Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page Marcus Lindner EPXC Published 11(16) / page 11 Pre-analysis Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-1001379436-P10-000-01-0056 RFQX: RFQX-1001379436-P10-000-01-0056 | 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. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Cybersecurity | Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 11 / page 11 Pre-analysis Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| RFQX-1001379436-P10-000-01-0057 RFQX: RFQX-1001379436-P10-000-01-0057 | Methods including the stipulation of a reasonable reporting time shall be proposed to and approved by the vehicle manufacturer. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 11 / page 11 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| REQ_SEC_0036 RFQX: RFQX-1001379436-P10-000-01-0058 | The supplier shall have a method for monitoring available vulnerability databases for vulnerabilities that can affect the delivered product. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Interface | Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 11 / page 11 Pre-analysis Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_SEC_0037 RFQX: RFQX-1001379436-P10-000-01-0059 | Identified vulnerabilities shall be considered in all current development projects or projects under field monitoring. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | System | Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 11 / page 11 Pre-analysis Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_SEC_0047 RFQX: RFQX-1001379436-P10-000-01-0060 | An ECU returned from field shall allow for field-return analysis. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Hardware | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page Product lifecycle / page 11 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| REQ_SEC_0048 RFQX: RFQX-1001379436-P10-000-01-0061 | Field-return analysis secrets shall not be operational in the field. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 11 / page 11 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_SEC_0049 RFQX: RFQX-1001379436-P10-000-01-0062 | An ECU enabled for field-return analysis shall not be possible to use as a spare part. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Hardware | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 11 / page 11 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| REQ_SEC_0050 RFQX: RFQX-1001379436-P10-000-01-0063 | All secrets specified by the vehicle manufacturer shall be protected throughout the lifecycle of the ECU. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Hardware | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page Marcus Lindner EPXC Published 12(16) / page 12 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RFQX-1001379436-P10-000-01-0064 RFQX: RFQX-1001379436-P10-000-01-0064 | End-of-life and decommissioning shall be specifically considered. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 12 / page 12 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-1001379436-P10-000-01-0065 RFQX: RFQX-1001379436-P10-000-01-0065 | Notes: a) It shall not be possible for a third party to reuse an ECU without system support from the vehicle manufacturer. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Hardware | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 12 / page 12 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-1001379436-P10-000-01-0066 RFQX: RFQX-1001379436-P10-000-01-0066 | b) Decommissioning of an ECU shall not have the potential of causing unacceptable risk to the road user or the vehicle manufacturer. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Hardware | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 12 / page 12 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| REQ_SEC_0051 RFQX: RFQX-1001379436-P10-000-01-0067 | Security related events shall be identified and logged. | 1001379436_P10_000_01_RDDM-1140152501-1744.pdf | Cybersecurity | Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page Logging / page 12 Pre-analysis Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| RFQX-3299216-1-0001 RFQX: RFQX-3299216-1-0001 | 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. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 3 / page 3 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| 2.1 RFQX: RFQX-3299216-1-0002 | The clutch actuator shall be electrically driven | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 4 / page 4 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 2.2 RFQX: RFQX-3299216-1-0003 | The actuator is placed outside of the gearbox | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 4 / page 4 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 2.3 RFQX: RFQX-3299216-1-0004 | The ECA (Electric Clutch Actuator) must have its own internal ECU for manoeuvring and error handling. | 3299216_1.pdf | Hardware | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 4 / page 4 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 2.4 RFQX: RFQX-3299216-1-0005 | The actuator will be controlled by a position and speed demand by CAN-bus | 3299216_1.pdf | Interface | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 4 / page 4 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 2.5 RFQX: RFQX-3299216-1-0006 | The actuator will be controlled by a position and speed demand by a 1kHz PWM signal on wake up connection | 3299216_1.pdf | Interface | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 4 / page 4 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 2.6 RFQX: RFQX-3299216-1-0007 | The ECA units shall be manufactured with marking variants according to the requirements in Scania STD19 (Ref 14.17). The variant type shall be based on delivery agreement and Brand involved. Variant 1: For Scania units, wordmark variant C1 Part number (7 digits). Variant 2: For MAN units, wordmark variant Z1. Part number (13 digits). Variant 3: For International units, wordmark variant X1. Part number (8 digits) Variant 4 Tentik wordmark variant W. Part number (9 digits, two spaces in format: 12 345 6789). 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. The marking shall not be visible when the ECA is mounted on a gearbox. The ECA units shall be delivered to the required Traton brand’s production in a position in the pallet where the marking is visible. | 3299216_1.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 4 / page 4 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0008 RFQX: RFQX-3299216-1-0008 | The variant type shall be based on delivery agreement and Brand involved. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 4 / page 4 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0009 RFQX: RFQX-3299216-1-0009 | 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. | 3299216_1.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 4 / page 4 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0010 RFQX: RFQX-3299216-1-0010 | The marking shall not be visible when the ECA is mounted on a gearbox. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 4 / page 4 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0011 RFQX: RFQX-3299216-1-0011 | The ECA units shall be delivered to the required Traton brand’s production in a position in the pallet where the marking is visible. | 3299216_1.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 4 / page 4 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| 2.7 RFQX: RFQX-3299216-1-0012 | The rubber cover (See req. 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. Date dial: CVM. 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 | 3299216_1.pdf | System | Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 5 / page 5 Pre-analysis Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| 2.8 RFQX: RFQX-3299216-1-0013 | The ECA shall be designed with Remanufacturing and/or Refurbishment in mind with possibility of swapping out larger electronic assemblies/components. Details to be agreed with Traton | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 5 / page 5 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 2.11 RFQX: RFQX-3299216-1-0014 | The mechanics shall also be tested and verified, in an overall durability test as stated in Appendix B etc. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 5 / page 5 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0015 RFQX: RFQX-3299216-1-0015 | 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. | 3299216_1.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 5 / page 5 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0016 RFQX: RFQX-3299216-1-0016 | Details to be agreed with Traton 2.9 Traton shall be invited to participate in electrical and mechanical design reviews. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 5 / page 5 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0017 RFQX: RFQX-3299216-1-0017 | 2.10 Traton requires extensive testing to be performed by the supplier to verify all demands stated in the requirement specification. | 3299216_1.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 5 / page 5 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0018 RFQX: RFQX-3299216-1-0018 | 2.12 Traton requires: - Documentation of the product, i.e. | 3299216_1.pdf | System | Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 5 / page 5 Pre-analysis Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0019 RFQX: RFQX-3299216-1-0019 | Should the PP be fully calculated from the AP-sensor, then this offset should not exist. | 3299216_1.pdf | Hardware | Non-mandatory wording; baseline inclusion not yet confirmed. | Needs internal review. Confirm whether this should-level requirement is in the committed baseline. | Decide baseline inclusion internally, then issue an Accept/Partial position. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 7 / page 7 Pre-analysis Non-mandatory wording; baseline inclusion not yet confirmed. Assumptions Internal baseline decision recorded. Engineering notes Complete internal review of wording and baseline scope. Risk / impact Limited; standard implementation and verification risk. |
| 4.1 RFQX: RFQX-3299216-1-0020 | The maximum release stroke is 22,4 mm from FCCP | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 8 / page 8 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 4.2 RFQX: RFQX-3299216-1-0021 | The total stroke of the actuator shall be 85 mm | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 8 / page 8 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 4.3 RFQX: RFQX-3299216-1-0022 | The clutch actuator shall be able to reach the extreme positions A and B in with the center of the pushrod end. Dimensions measured on the ECA. See Figure 3 - Pushrod positions. Figure 3 - Pushrod positions | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 3299216_1 > Page 8 / page 8 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 4.5 RFQX: RFQX-3299216-1-0023 | The gearbox flange designated to the ECA has three different surfaces, see Figure 5 Gearbox flange. Surface A, which is machined pressure die cast aluminium that can act both as a heat source and heat sink for the ECA Surface B which is a raw pressure die casted surface. Surface C which is a rubber grommet, that does not require any different interface compared to the surrounding surface A. | 3299216_1.pdf | Interface | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 9 / page 9 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 4.6 RFQX: RFQX-3299216-1-0024 | 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. The rubber grommet at the lower part of the flange can have the same interface as the surrounding aluminum flange. | 3299216_1.pdf | IT / backend | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 9 / page 9 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| 4.7 RFQX: RFQX-3299216-1-0025 | 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. The surface roughness of the ECA opposite to surface B shall be equal or finer than Ra 3,2 µm. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 9 / page 9 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 4.8 RFQX: RFQX-3299216-1-0026 | The ECA shall be adapted for 6 pcs M8 flange screws described by Scania STD4435 | 3299216_1.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 9 / page 9 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| 53612101 RFQX: RFQX-3299216-1-0027 | P 1 Page 4.4 ECA shall not interfere with any geometry in the 3D envelope -1 1_RFQ2030.stp except where interference fits or other types of functional contacts are required. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 3299216_1 > Page 9 / page 9 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0028 RFQX: RFQX-3299216-1-0028 | The surface roughness of the ECA opposite to surface B shall be equal or finer than Ra 3,2 µm. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 9 / page 9 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| 4.9 RFQX: RFQX-3299216-1-0029 | The ECA shall be adapted for 2 pcs 10 mm guide pins Figure 5 - Gearbox flange | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 3299216_1 > Page 10 / page 10 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 4.10 RFQX: RFQX-3299216-1-0030 | The guide pin holes in the ECA shall be Ø 10,1±0.05 mm and at least 12 mm deep. The holes shall also block the guide pin from protruding more than 14 mm from the gearbox housing. Both depths measured from the center of the oval hole in the Gearbox/ECA flange. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 10 / page 10 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 4.11 RFQX: RFQX-3299216-1-0031 | The ECA shall be able to be held by the guide pins only while being exposed to the max clutch load, (req. 4.22) up to 50 times. The clutch load will be removed and the screw interface tightened between every load occasion. Surface indents in the contacts are allowed as long as the structural integrity is unaffected | 3299216_1.pdf | Interface | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 10 / page 10 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| 4.12 RFQX: RFQX-3299216-1-0032 | The pushrod end that makes contact with the clutch lever shall be a Ø15,93±0,07 mm steel sphere. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 10 / page 10 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 4.13 RFQX: RFQX-3299216-1-0033 | 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. Alternatively it can have a loose fit in the ECA, but it shall be possible to reconnect it by pushing it back by hand. | 3299216_1.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 10 / page 10 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| 4.14 RFQX: RFQX-3299216-1-0034 | The ECA shall allow space for external tools according to the cylinders in the 3D envelope attached. | 3299216_1.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 10 / page 10 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| 4.15 RFQX: RFQX-3299216-1-0035 | The ECA shall have a window where the volume shown in Figure 6 – Snap in tool space, could pass through(See req. 4.4). | 3299216_1.pdf | Tooling | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 10 / page 10 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| 4.16 RFQX: RFQX-3299216-1-0036 | The ECA shall provide a support for a clutch snap in tool on the marked surface in Figure 4 ISO view of 3D envelope. The maximum force is 1kN. Surface indents are allowed as long as it does not affect other requirements or the structural integrity of the ECA. | 3299216_1.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 10 / page 10 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RFQX-3299216-1-0037 RFQX: RFQX-3299216-1-0037 | The holes shall also block the guide pin from protruding more than 14 mm from the gearbox housing. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 10 / page 10 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0038 RFQX: RFQX-3299216-1-0038 | Alternatively it can have a loose fit in the ECA, but it shall be possible to reconnect it by pushing it back by hand. | 3299216_1.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 10 / page 10 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| 4.17 RFQX: RFQX-3299216-1-0039 | The hole shall be equipped with a cover possible to assemble and disassemble at least 50 times without tools. If an interference fit is chosen, the maximum force to assemble/disassemble shall be 50 N in room temperature. It shall still remain intac t and keep tightness after vibration testing (See req.10.5) | 3299216_1.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 11 / page 11 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| 4.18 RFQX: RFQX-3299216-1-0040 | 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. A wire could be used as test object. Figure 6 - Snap in tool space | 3299216_1.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 3299216_1 > Page 11 / page 11 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| 4.19 RFQX: RFQX-3299216-1-0041 | The ECA shall have a loop or similar feature where the cable can be fixated with a cable tie Optionally an M8 screw thread and rotation stop for a sheet metal bracket indicated in Figure 4 - ISO view of 3D envelope, can be provided. 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 | 3299216_1.pdf | Hardware | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 11 / page 11 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| 4.20 RFQX: RFQX-3299216-1-0042 | The connector for communication and power shall be positioned as indicated in Figure 4 ISO view of 3D envelope, when connected. Details regarding actual length and positioning tolerances shall be agreed in design phase. | 3299216_1.pdf | Hardware | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 11 / page 11 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| 4.21 RFQX: RFQX-3299216-1-0043 | 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. | 3299216_1.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 11 / page 11 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0044 RFQX: RFQX-3299216-1-0044 | If an interference fit is chosen, the maximum force to assemble/disassemble shall be 50 N in room temperature. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 11 / page 11 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0045 RFQX: RFQX-3299216-1-0045 | Details regarding actual length and positioning tolerances shall be agreed in design phase. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 11 / page 11 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| 4.22 RFQX: RFQX-3299216-1-0046 | The clutch force acting on the pushrod is defined in Appendix A | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 12 / page 12 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 4.23 RFQX: RFQX-3299216-1-0047 | The actuator shall apply a preload force for the release bearing. The preload force measured on the push rod shall be 150N to 250N independent of the clutch position | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 12 / page 12 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 4.24 RFQX: RFQX-3299216-1-0048 | The pushrod position when clutch is at rest and only preload force is applied, will vary randomly within 2 mm (± 1mm from FCCP). | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 12 / page 12 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 4.25 RFQX: RFQX-3299216-1-0049 | It must be possible to assemble the actuator independent of the lever position without any power connection. This means that the push rod shall be possible to move by hand. Maximum force allowed is 300N. | 3299216_1.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 12 / page 12 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0050 RFQX: RFQX-3299216-1-0050 | This means that the push rod shall be possible to move by hand. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 12 / page 12 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0051 RFQX: RFQX-3299216-1-0051 | 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. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 12 / page 12 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| REQ 5.10 RFQX: RFQX-3299216-1-0052 | 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 ,and max speed set to 125mm/s (see | 3299216_1.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 13 / page 13 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| REQ 6.4 RFQX: RFQX-3299216-1-0053 | ) 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. | 3299216_1.pdf | IT / backend | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 3299216_1 > Page 13 / page 13 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-3299216-1-0054 RFQX: RFQX-3299216-1-0054 | This shall be measured against the maximum disengage force (See Appendix A) Figure 7 – Maximum disengage time | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 13 / page 13 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| REQ 6.4 RFQX: RFQX-3299216-1-0055 | 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 ). | 3299216_1.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 3299216_1 > Page 14 / page 14 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0056 RFQX: RFQX-3299216-1-0056 | This shall be measured against the minimum engage force (See Appendix A) Figure 8 - Maximum engage time | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 14 / page 14 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| 5.3 RFQX: RFQX-3299216-1-0057 | The clutch actuator shall report the absolute position of the current actuator stroke (AP) (Ref 14.14). | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 15 / page 15 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 5.4 RFQX: RFQX-3299216-1-0058 | 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. 6.5). | 3299216_1.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 15 / page 15 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 5.5 RFQX: RFQX-3299216-1-0059 | The clutch actuator shall be equipped with a displacement sensor measuring the movement of the push rod, (Ref 14.14) | 3299216_1.pdf | Hardware | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 15 / page 15 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 5.6 RFQX: RFQX-3299216-1-0060 | 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. Resolution (smallest discernible unit of change along the X axis): 0.0125mm. Repeatability (maximum variation between measurements at the same position and in the same unit, with equal environmental conditions): +/- 0.1mm. Range: 85mm (AP) | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 15 / page 15 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 5.7 RFQX: RFQX-3299216-1-0061 | For each stroke that the actuator performs it shall adjust to the current wear of the clutch. 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. 5.10. The implementation can be either a pure mechanical solution or it can be implemented using a software based solution. | 3299216_1.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 15 / page 15 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| 5.9 RFQX: RFQX-3299216-1-0062 | The maximum stationary position error relative to real FCCP (i e self-adjustment error + step response error) shall be ±0.15mm. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 15 / page 15 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0063 RFQX: RFQX-3299216-1-0063 | 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. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 15 / page 15 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0064 RFQX: RFQX-3299216-1-0064 | 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. | 3299216_1.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 15 / page 15 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0065 RFQX: RFQX-3299216-1-0065 | 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. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 16 / page 16 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0066 RFQX: RFQX-3299216-1-0066 | The actuator shall move the pushrod at the highest possible speed, limited only by its maximum achievable speed and the maximum speed request. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 16 / page 16 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0067 RFQX: RFQX-3299216-1-0067 | 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. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 16 / page 16 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0068 RFQX: RFQX-3299216-1-0068 | Dynamics end of movement: The requested speed shall be kept until 2 mm from the target position. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 16 / page 16 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0069 RFQX: RFQX-3299216-1-0069 | 100ms after reaching 2 mm from target, the maximum position error should be ±0.1mm. | 3299216_1.pdf | System | Non-mandatory wording; baseline inclusion not yet confirmed. | Needs internal review. Confirm whether this should-level requirement is in the committed baseline. | Decide baseline inclusion internally, then issue an Accept/Partial position. | ASSUMPTION BASED | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 16 / page 16 Pre-analysis Non-mandatory wording; baseline inclusion not yet confirmed. Assumptions Internal baseline decision recorded. Engineering notes Complete internal review of wording and baseline scope. Risk / impact Limited; standard implementation and verification risk. |
| REQ 5.1 RFQX: RFQX-3299216-1-0070 | Maximum overshoot is 0.2 mm When a new position is requested, but the stroke is too short to reach requested speed, the ECA shall complete the stroke in minimum time with dynamic in compliance with the , 5.2 and this section. | 3299216_1.pdf | Process / compliance | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 3299216_1 > Page 16 / page 16 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 5.11 RFQX: RFQX-3299216-1-0071 | Req. 5.10 shall be tested with a step response test cycle, according to description and Figure 10 - Step response test cycle. Step from FCCP to 0.5x fully open position Wait 2 seconds Step to fully open position Wait 2 seconds Step to 0.5x fully open position Wait 2 seconds Step to FCCP Figure 10 - Step response test cycle | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 3299216_1 > Page 17 / page 17 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0072 RFQX: RFQX-3299216-1-0072 | 5.10 shall be tested with a step response test cycle, according to description and Figure 10 - Step response test cycle. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 17 / page 17 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0073 RFQX: RFQX-3299216-1-0073 | 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. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 18 / page 18 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| REQ 8.1 RFQX: RFQX-3299216-1-0074 | The test shall be done with the highest operating temperature (see ) and maximum clutch force (See Appendix A) Figure 11 - Release frequency test | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 3299216_1 > Page 18 / page 18 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 5.14 RFQX: RFQX-3299216-1-0075 | It shall be possible to keep the clutch disengaged continuously without risk of loss of function for 120 min. This shall be measured against the maximum disengage force (Appendix A) and an highest operating temperature (see req. 8.1). | 3299216_1.pdf | Software | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 19 / page 19 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0076 RFQX: RFQX-3299216-1-0076 | Between 16V and loss of power the ECA shall hold its current position or move towards requested position without any time requirement. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 19 / page 19 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0077 RFQX: RFQX-3299216-1-0077 | The strategy shall be disc ussed and approved with Traton. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 19 / page 19 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0078 RFQX: RFQX-3299216-1-0078 | This shall be measured against the maximum disengage force (Appendix A) and an highest operating temperature (see req. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 19 / page 19 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| 6.2 RFQX: RFQX-3299216-1-0079 | The ECA will be controlled by messages on the CAN bus and by the PWM signal specified in req. 7.24-7.33. The CAN communication messages are specified in PD2497100 (Ref 14.14). It shall be followed to its full extent. If needed, some messages might be complemented with additional checksums and message counters | 3299216_1.pdf | IT / backend | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 20 / page 20 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| 6.3 RFQX: RFQX-3299216-1-0080 | Req. 6.3.1 to 6.3.5 describe the various control modes that can be requested via CAN (Ref 14.14) | 3299216_1.pdf | Interface | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 20 / page 20 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-3299216-1-0081 RFQX: RFQX-3299216-1-0081 | P 1 Page 6 SW functionality 6.1 TB4684 shall be applied. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 20 / page 20 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0082 RFQX: RFQX-3299216-1-0082 | It shall be followed to its full extent. | 3299216_1.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 20 / page 20 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| 6.3.1 RFQX: RFQX-3299216-1-0083 | When requesting Absolute Position Control the actuator shall move to the actuator position defined by the Requested Position (RP). The RP can in this mode correspond to the full wear travel of the clutch (see req. 4.3) It is allowed to control movement to protect the ECA and clutch from hardware damage. Specific cases shall be approved with Traton. Control mode Absolute position 0x01 | 3299216_1.pdf | Hardware | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 21 / page 21 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| 6.3.2 RFQX: RFQX-3299216-1-0084 | Control (RPC) the actuator shall move to an offset that corresponds to the Requested Position from the Fully Closed Clutch Position (FCCP). The RP can be up to a full Release Travel (22,4 mm) in this mode. How the FCCP can be identified is described in 6.5. When RP = 0 the actuator is allowed to have a position that is less than the FCCP but not more, since this would open the clutch. Control mode Relative position 0x02 | 3299216_1.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 21 / page 21 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0085 RFQX: RFQX-3299216-1-0085 | When requesting Absolute Position Control the actuator shall move to the actuator position defined by the Requested Position (RP). | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 21 / page 21 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0086 RFQX: RFQX-3299216-1-0086 | Specific cases shall be approved with Traton. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 21 / page 21 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0087 RFQX: RFQX-3299216-1-0087 | Control mode Relative position 0x02 6.3.3 When requesting Torque Control (TC) the actuator shall actuate the requested motor torque. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 21 / page 21 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| 6.4 RFQX: RFQX-3299216-1-0088 | A maximum allowed speed of the actuator is sent as a separate signal on CAN. If the actuator can move faster than this value it shall be controlled in a such way that it does not exceed this limit. | 3299216_1.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 22 / page 22 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| 6.5.2 RFQX: RFQX-3299216-1-0089 | The value shall be frozen at the last identified position and used for RPC. Self-adjustment disabled 0x3 | 3299216_1.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | High | Analysis detailsSource section/page 3299216_1 > Page 22 / page 22 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0090 RFQX: RFQX-3299216-1-0090 | 6.3.4 When requesting Test Mode, the actuator shall perform tests to detect latent faults. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 22 / page 22 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0091 RFQX: RFQX-3299216-1-0091 | 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. | 3299216_1.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 22 / page 22 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0092 RFQX: RFQX-3299216-1-0092 | CAN communication shall still be active. | 3299216_1.pdf | Interface | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 22 / page 22 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0093 RFQX: RFQX-3299216-1-0093 | If the actuator can move faster than this value it shall be controlled in a such way that it does not exceed this limit. | 3299216_1.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 22 / page 22 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RFQX-3299216-1-0094 RFQX: RFQX-3299216-1-0094 | 6.5 Self-adjustment The self-adjustment signal defines the restrictions of how the FCCP shall be identified. | 3299216_1.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 22 / page 22 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| REQ 6.3 RFQX: RFQX-3299216-1-0095 | ). | 3299216_1.pdf | Interface | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page The signal is valid during Control Modes RPC and TC(see / page 22 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-3299216-1-0096 RFQX: RFQX-3299216-1-0096 | The value of the FCCP shall be reported via CAN(Ref 14.14) Req. | 3299216_1.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 22 / page 22 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0097 RFQX: RFQX-3299216-1-0097 | The value shall be frozen at the last identified position and used for RPC. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 22 / page 22 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| 6.6 RFQX: RFQX-3299216-1-0098 | Accuracy mode | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 23 / page 23 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 6.7 RFQX: RFQX-3299216-1-0099 | Not applicable. | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 23 / page 23 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 6.8 RFQX: RFQX-3299216-1-0100 | Feedback from the ECA will also be sent via CAN. Specific error reporting as per req. 6.13. Message contents to be agreed with Traton | 3299216_1.pdf | Interface | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 23 / page 23 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 6.9 RFQX: RFQX-3299216-1-0101 | The ECA shall report a unique ECA individual identification number | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 23 / page 23 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 6.10 RFQX: RFQX-3299216-1-0102 | The ECA shall report supplier code 5 via CAN. | 3299216_1.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 23 / page 23 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| 6.11 RFQX: RFQX-3299216-1-0103 | The ECA shall report a complete SW version number. The number is decided by the supplier and can be in the range 0-64255. | 3299216_1.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 23 / page 23 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| 6.12 RFQX: RFQX-3299216-1-0104 | The ECA shall report a complete HW version number. The number is decided by the supplier and can be in the range 0-64255. | 3299216_1.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 23 / page 23 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| 6.14 RFQX: RFQX-3299216-1-0105 | The ECA shall report its current System State. Valid states are explained in requirements 6.14.1 - 6.14.9. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 23 / page 23 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0106 RFQX: RFQX-3299216-1-0106 | 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. | 3299216_1.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 23 / page 23 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| REQ 6.20 RFQX: RFQX-3299216-1-0107 | 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 , | 3299216_1.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 3299216_1 > Page 23 / page 23 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| REQ 6.22 RFQX: RFQX-3299216-1-0108 | ,req. | 3299216_1.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 23 / page 23 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-3299216-1-0109 RFQX: RFQX-3299216-1-0109 | ESA definition( Ref 14.16) The supplier shall provide documentation for the ESD bits and related faults . | 3299216_1.pdf | System | Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 23 / page 23 Pre-analysis Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| 6.14.2 RFQX: RFQX-3299216-1-0110 | This value shall be sent when the ECA is actuating Absolute Position Control. 0x1 | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 24 / page 24 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 6.14.3 RFQX: RFQX-3299216-1-0111 | This value shall be sent when the ECA is actuating Relative Position Control. 0x2 | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 24 / page 24 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 6.14.4 RFQX: RFQX-3299216-1-0112 | This value shall be sent when the ECA is actuating Torque Control. The torque being controlled is the torque of the motor. 0x4 | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 24 / page 24 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 6.14.5 RFQX: RFQX-3299216-1-0113 | 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. passing FCCP). 0x5 | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 24 / page 24 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 6.14.6 RFQX: RFQX-3299216-1-0114 | This value shall be sent when the ECA is performing its initiation routine and is not yet available for control. 0xA | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 24 / page 24 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 6.14.8 RFQX: RFQX-3299216-1-0115 | This value shall be sent when the actuator is in debug or test control state. 0xC | 3299216_1.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 24 / page 24 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| 6.14.9 RFQX: RFQX-3299216-1-0116 | This value shall be sent when the actuator is performing a motor brake simulation. 0xD | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 24 / page 24 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0117 RFQX: RFQX-3299216-1-0117 | 6.14.1 Boot Mode If the actuator is in boot mode, 0x00 shall be reported as active state. | 3299216_1.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 24 / page 24 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0118 RFQX: RFQX-3299216-1-0118 | 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. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 24 / page 24 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| 6.15 RFQX: RFQX-3299216-1-0119 | The ECA shall report the current system temperature.(Ref 14.14) | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 25 / page 25 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 6.16 RFQX: RFQX-3299216-1-0120 | The ECA shall calculate and report the actuator motor torque. (Ref 14.14) | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 25 / page 25 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 6.17 RFQX: RFQX-3299216-1-0121 | The ECA shall report the current for each phase of the actuator. These values shall be calculated using a moving mean filter. The filter time shall equal the update frequency . (Ref 14.14) | 3299216_1.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 3299216_1 > Page 25 / page 25 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| 6.18 RFQX: RFQX-3299216-1-0122 | The ECA shall report the current system voltage. (input voltage) (Ref 14.14) | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 25 / page 25 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 6.19.1 RFQX: RFQX-3299216-1-0123 | The ECA shall store and report its accumulated operational hours. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 25 / page 25 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 6.19.2 RFQX: RFQX-3299216-1-0124 | The ECA shall report its accumulated lifetime travel length. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 25 / page 25 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 6.20 RFQX: RFQX-3299216-1-0125 | CVS120 shall be applied (Ref 14.12). | 3299216_1.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 25 / page 25 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| 6.21 RFQX: RFQX-3299216-1-0126 | Cybersecurity shall be considered through a separate process with the latest Traton workflow in mind. The following apply: Mandatory: TRATON secure updates - CVS31,CVS32,CVS123-2,CVS154 TRATON secure diagnostics - CVS31,CVS32,CVS151 TRATON Specification on Unified diagnostic Services CVS124 Other applicable documents considered as supporting specifications: CVS30, CVS33, CVS34,CVS121,CVS122,SecureBoot,Vehicle Baseline Requirements, ECU Baseline Requirements Additional standards/documents will be made available, if applicable. | 3299216_1.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 3299216_1 > Page 25 / page 25 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| 6.22 RFQX: RFQX-3299216-1-0127 | Minimum diagnostic feedback described in req. 6.22.1 - 6.22.11. | 3299216_1.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 3299216_1 > Page 25 / page 25 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 6.22.1 RFQX: RFQX-3299216-1-0128 | Wrong rotation direction | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 25 / page 25 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 6.22.2 RFQX: RFQX-3299216-1-0129 | Short circuit / open load on the phases | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 25 / page 25 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 6.22.3 RFQX: RFQX-3299216-1-0130 | Motor rotation feedback, short circuit / open load | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 25 / page 25 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-3299216-1-0131 RFQX: RFQX-3299216-1-0131 | These values shall be calculated using a moving mean filter. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 25 / page 25 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0132 RFQX: RFQX-3299216-1-0132 | The filter time shall equal the update frequency . | 3299216_1.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 25 / page 25 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| 6.23 RFQX: RFQX-3299216-1-0134 | The reported ESD must be able to be validated and invalidated. | 3299216_1.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 27 / page 27 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| 6.24 RFQX: RFQX-3299216-1-0135 | 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. One unique DTC will be set per bit in the ESD signal. If higher resolution is required for the supplier to properly troubleshoot any individual occurrence, then the ECA is responsible for storing these parameters internally. Internally stored parameters may be accessible only using supplier defined tools . | 3299216_1.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 27 / page 27 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| 6.25 RFQX: RFQX-3299216-1-0136 | Any data logged or stored shall be agreed upon together with Traton. | 3299216_1.pdf | System | Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 27 / page 27 Pre-analysis Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| 6.26 RFQX: RFQX-3299216-1-0137 | 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. 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. This could be designed with for example data mirroring. It is acceptable if purely statistical data (e.g. operation hours) from the active operation cycle is not stored in case of an abnormal shutdown. | 3299216_1.pdf | Software | Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 27 / page 27 Pre-analysis Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| 6.27 RFQX: RFQX-3299216-1-0138 | 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. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 27 / page 27 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 6.28 RFQX: RFQX-3299216-1-0139 | It shall be possible to reset the ECA application with a power off/on cycle after all functional safety events. Handling to be agreed with Traton. | 3299216_1.pdf | Software | Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 27 / page 27 Pre-analysis Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0140 RFQX: RFQX-3299216-1-0140 | If higher resolution is required for the supplier to properly troubleshoot any individual occurrence, then the ECA is responsible for storing these parameters internally. | 3299216_1.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 27 / page 27 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0141 RFQX: RFQX-3299216-1-0141 | Internally stored parameters may be accessible only using supplier defined tools . | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 27 / page 27 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-3299216-1-0142 RFQX: RFQX-3299216-1-0142 | 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. | 3299216_1.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 27 / page 27 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| 7.1 RFQX: RFQX-3299216-1-0143 | The electrical design must ensure that an internal short circuit through one of H -bridges (“shoot through”) is avoided. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 28 / page 28 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 7.3 RFQX: RFQX-3299216-1-0144 | A safe boot sequence must be set to prevent unwanted or undefined behavior during or after loss of power, or corruption of stored data. | 3299216_1.pdf | System | Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 28 / page 28 Pre-analysis Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| 7.4 RFQX: RFQX-3299216-1-0145 | 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. Relates to Safety Goals set in PD3339794 (Ref 14.16). | 3299216_1.pdf | Hardware | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 28 / page 28 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 7.5 RFQX: RFQX-3299216-1-0146 | All external electrical connectors shall be geometrically coded. If internal components are included in repair kits, the internal electrical connectors shall also be geometrically coded. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 28 / page 28 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 7.6 RFQX: RFQX-3299216-1-0147 | 2*6.3mm (MCP) 6*2.8mm (MCP) Code A TE part no.: 1-2299782-1 Pin list with: Pin distribution, Pin size (see req. 7.41) | 3299216_1.pdf | Hardware | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 28 / page 28 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-3299216-1-0148 RFQX: RFQX-3299216-1-0148 | 7.2 Short circuit protection shall be implemented by hardware. | 3299216_1.pdf | Hardware | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 28 / page 28 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0149 RFQX: RFQX-3299216-1-0149 | If internal components are included in repair kits, the internal electrical connectors shall also be geometrically coded. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 28 / page 28 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0150 RFQX: RFQX-3299216-1-0150 | 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. | 3299216_1.pdf | Hardware | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 28 / page 28 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| 7.10 RFQX: RFQX-3299216-1-0151 | 6.3mm Tin, Sn ≥3 μm thick. ≥1 µm Ni | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 29 / page 29 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 7.11 RFQX: RFQX-3299216-1-0152 | 2.8mm Gold, Au ≥0,8 μm thick. ≥1 µm Ni | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 29 / page 29 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 7.12 RFQX: RFQX-3299216-1-0153 | The ECA can be connected to the battery+ (30) permanently through the system fuse or through a master switch that physically cuts off power. All power used by the ECA shall be taken from this battery connection. | 3299216_1.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 29 / page 29 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| 7.13 RFQX: RFQX-3299216-1-0154 | The ECA is connected directly to the battery GND (31). This ground connection will act as system ground and reference for the entire ECA. The ground shall not be DC connected to the ECA housing. Requirements Power cable dimension: Operating parameters Remark Min Typ. Max. Unit | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 29 / page 29 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 7.15 RFQX: RFQX-3299216-1-0155 | Power cable length: - - 2*6000 mm | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 29 / page 29 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 7.16 RFQX: RFQX-3299216-1-0156 | A 1. According to ISO 8820-5:2015 SF30 type fuse-links. 2. According to ISO 8820-5:2015 SF51 type fuse-links. | 3299216_1.pdf | Process / compliance | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 29 / page 29 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 7.17 RFQX: RFQX-3299216-1-0157 | Umax: - - 32/36/48 A Specific test relations TBD | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 29 / page 29 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 7.18 RFQX: RFQX-3299216-1-0158 | CVS41 limits may go below this value. Valid only for ECU and communication function. For clutch actuation see req. 5.13 | 3299216_1.pdf | Software | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 29 / page 29 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 7.20 RFQX: RFQX-3299216-1-0159 | Figure 133 A 3. Up to 100 kHz | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 3299216_1 > Page 29 / page 29 Pre-analysis Source classifies this as Unknown (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-3299216-1-0160 RFQX: RFQX-3299216-1-0160 | All power used by the ECA shall be taken from this battery connection. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 29 / page 29 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0161 RFQX: RFQX-3299216-1-0161 | The ground shall not be DC connected to the ECA housing. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 29 / page 29 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0162 RFQX: RFQX-3299216-1-0162 | 7.23 Quiescent current: According to CVS41 (Ref 14.2), must be met independent of input and output conditions. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 30 / page 30 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0163 RFQX: RFQX-3299216-1-0163 | It shall be used to control the power up sequence to the µP. | 3299216_1.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 31 / page 31 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0164 RFQX: RFQX-3299216-1-0164 | The Wake-up signal shall also be connected to a digital input on the µP. | 3299216_1.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 31 / page 31 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0165 RFQX: RFQX-3299216-1-0165 | Special precautions shall be taken to prevent direct connection between Wake-up and 30 in case of a single failure. | 3299216_1.pdf | System | Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 31 / page 31 Pre-analysis Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0166 RFQX: RFQX-3299216-1-0166 | 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. | 3299216_1.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 31 / page 31 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0167 RFQX: RFQX-3299216-1-0167 | 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. | 3299216_1.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 31 / page 31 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0168 RFQX: RFQX-3299216-1-0168 | 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. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 31 / page 31 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0169 RFQX: RFQX-3299216-1-0169 | Redundancies due improper shutdown shall be aligned with Traton. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 31 / page 31 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0170 RFQX: RFQX-3299216-1-0170 | If a signal for disengaging the clutch is received the ECA shall actuate the request regardless of CAN-request. | 3299216_1.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 33 / page 33 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| 7.34 RFQX: RFQX-3299216-1-0171 | The ECA has one CAN bus. Any watchdog circuit shall have no influence on the CAN bus The CAN front end shall be designed to comply with TB1905 (Ref 14.3), with the following additional information in this chapter. | 3299216_1.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 34 / page 34 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| 7.35 RFQX: RFQX-3299216-1-0172 | The controller and transceiver shall be CAN FD ready Parameter Limit values Unit Remarks Min. Typ. Max. | 3299216_1.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 34 / page 34 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| 7.38 RFQX: RFQX-3299216-1-0173 | CAN FD: 4000 - - kbit/s Figure 15 - Reference circuit | 3299216_1.pdf | Interface | Source classifies this as Unknown (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 3299216_1 > Page 34 / page 34 Pre-analysis Source classifies this as Unknown (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-3299216-1-0174 RFQX: RFQX-3299216-1-0174 | Any watchdog circuit shall have no influence on the CAN bus. | 3299216_1.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 34 / page 34 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0175 RFQX: RFQX-3299216-1-0175 | The CAN front end shall be designed to comply with TB1905 (Ref 14.3), with the following additional information in this chapter. | 3299216_1.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 34 / page 34 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0176 RFQX: RFQX-3299216-1-0176 | 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. | 3299216_1.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 34 / page 34 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| 7.39 RFQX: RFQX-3299216-1-0177 | 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. | 3299216_1.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 35 / page 35 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| 7.40 RFQX: RFQX-3299216-1-0178 | CAN shield. Footprint prepared for internal connection to system ground 31_ECA via a resistor and a capacitor in series. The components shall not be populated by default. The CAN front end shall be designed to comply with TB1905. (Ref 14.3) | 3299216_1.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 35 / page 35 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0179 RFQX: RFQX-3299216-1-0179 | The components shall not be populated by default. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 35 / page 35 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0180 RFQX: RFQX-3299216-1-0180 | The CAN front end shall be designed to comply with TB1905. | 3299216_1.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 35 / page 35 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| 7.45 RFQX: RFQX-3299216-1-0181 | The air inside the electronics enclosure shall be ventilated with the use of a membrane. 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. The membrane shall be placed so that it is protected against blunt force, falling dust and dripping salt-water. The design shall be made to prevent accumulation of water on top of the membrane, or in the cavity of the membrane. | 3299216_1.pdf | IT / backend | Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 36 / page 36 Pre-analysis Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RFQX-3299216-1-0182 RFQX: RFQX-3299216-1-0182 | The quality of the wire bonding and position shall be properly analyzed. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 36 / page 36 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0183 RFQX: RFQX-3299216-1-0183 | The material shall be lead free and of ”high temperatures solder type”. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 36 / page 36 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0184 RFQX: RFQX-3299216-1-0184 | The melting point of the soldering material and the composition of the soldering material shall be declared by supplier. | 3299216_1.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 36 / page 36 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0185 RFQX: RFQX-3299216-1-0185 | The PCB must be supported and must not bent in any direction during the process. | 3299216_1.pdf | Process / compliance | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 36 / page 36 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0186 RFQX: RFQX-3299216-1-0186 | Conformal coating or lacquer shall cover the entire PCB and all solder joints. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 36 / page 36 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0187 RFQX: RFQX-3299216-1-0187 | 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. | 3299216_1.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 36 / page 36 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0188 RFQX: RFQX-3299216-1-0188 | shall be specified in the initial offer. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 36 / page 36 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0189 RFQX: RFQX-3299216-1-0189 | The conformal coating process and materials shall apply to the latest versions of IPC/EIA J-STD-001 (with applicable standards as e.g. | 3299216_1.pdf | Process / compliance | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 36 / page 36 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0190 RFQX: RFQX-3299216-1-0190 | 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. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 36 / page 36 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0191 RFQX: RFQX-3299216-1-0191 | Water based and silicone lacquers shall not be used. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 36 / page 36 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0192 RFQX: RFQX-3299216-1-0192 | 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. | 3299216_1.pdf | System | Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 36 / page 36 Pre-analysis Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0193 RFQX: RFQX-3299216-1-0193 | The membrane shall be placed so that it is protected against blunt force, falling dust and dripping salt-water. | 3299216_1.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 36 / page 36 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0194 RFQX: RFQX-3299216-1-0194 | The design shall be made to prevent accumulation of water on top of the membrane, or in the cavity of the membrane. | 3299216_1.pdf | System | Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 36 / page 36 Pre-analysis Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0195 RFQX: RFQX-3299216-1-0195 | 7.46 Forbidden components: BGA capsule in any form must not be used. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 36 / page 36 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0196 RFQX: RFQX-3299216-1-0196 | Tantalum capacitors must not be used Serial resistors on power supply circuits must not be used. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 36 / page 36 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| 8.2 RFQX: RFQX-3299216-1-0197 | The life length requirement is minimum 3000 operating hours per year for 15 years | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 38 / page 38 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 8.3 RFQX: RFQX-3299216-1-0198 | The clutch actuator shall withstand 6 500 000 actuations with the test cycle described in Appendix B. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 38 / page 38 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 8.5 RFQX: RFQX-3299216-1-0199 | The ECA must be maintenance free over the whole life time | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 38 / page 38 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 8.8 RFQX: RFQX-3299216-1-0200 | The maintenance window cover (See req. 4.17) shall be provided as a spare part | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 38 / page 38 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 8.9 RFQX: RFQX-3299216-1-0201 | 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. It is allowed to destroy the ECA in the process. | 3299216_1.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 38 / page 38 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0202 RFQX: RFQX-3299216-1-0202 | 8.4 Six consecutive units shall run past 6.5M actuations at the supplier, and continue to end of life. | 3299216_1.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 38 / page 38 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0203 RFQX: RFQX-3299216-1-0203 | Three consecutive units shall run past 6.5M actuations at Scania, and continue to end of life. | 3299216_1.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 38 / page 38 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0204 RFQX: RFQX-3299216-1-0204 | 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. | 3299216_1.pdf | Hardware | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 38 / page 38 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0205 RFQX: RFQX-3299216-1-0205 | Spare parts or repair kits shall be defined together in agreement. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 38 / page 38 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0206 RFQX: RFQX-3299216-1-0206 | 4.17) shall be provided as a spare part. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 38 / page 38 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| 9.1 RFQX: RFQX-3299216-1-0207 | The ECA shall fulfil the requirements stated in STD3868 STD3868 is a comprehensive document referring to several underlying standards. 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. STD4159, Chemical substances with limited use – Scania Grey list. CVS 83, Material declaration according to Scania IMDS reporting std. The different parts of the housing shall be marked according to material content. The ECA shall be lead free. | 3299216_1.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 39 / page 39 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| 9.2 RFQX: RFQX-3299216-1-0208 | 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. For type approval, the vehicle and its components shall comply with ECE Regulation No. 105 and with European Directive 2008/68/EC, as amended. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 39 / page 39 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0209 RFQX: RFQX-3299216-1-0209 | 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. | 3299216_1.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 39 / page 39 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0210 RFQX: RFQX-3299216-1-0210 | The different parts of the housing shall be marked according to material content. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 39 / page 39 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0211 RFQX: RFQX-3299216-1-0211 | The ECA shall be lead free. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 39 / page 39 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0212 RFQX: RFQX-3299216-1-0212 | For type approval, the vehicle and its components shall comply with ECE Regulation No. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 39 / page 39 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| 10.1 RFQX: RFQX-3299216-1-0213 | 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). | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 40 / page 40 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 10.2 RFQX: RFQX-3299216-1-0214 | The ECA must not be dependent on software for protection against requirements stated in CVS40 (Ref 14.1) and CVS41 (Ref 14.2). | 3299216_1.pdf | Software | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 40 / page 40 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0215 RFQX: RFQX-3299216-1-0215 | CAN communication shall not be affected. | 3299216_1.pdf | Interface | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 40 / page 40 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0216 RFQX: RFQX-3299216-1-0216 | Memory functions shall remain Class A. | 3299216_1.pdf | Hardware | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 40 / page 40 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0217 RFQX: RFQX-3299216-1-0217 | Accepted behaviour in this case shall be agreed upon between Traton and Supplier. | 3299216_1.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 40 / page 40 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| 10.4 RFQX: RFQX-3299216-1-0218 | 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. This test shall be performed before and after exposure. 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. This test shall be possible to perform during exposure. Reduced versions of test procedure II may be agreed and used during various tests. Alternative 1: Test cycle according to Appendix B, frequency 10 to 30 strokes per minute. Alternative 2: Release frequency test according to req. 5.12. | 3299216_1.pdf | Software | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 3299216_1 > Page 41 / page 41 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0219 RFQX: RFQX-3299216-1-0219 | This test shall be performed before and after exposure. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 41 / page 41 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0220 RFQX: RFQX-3299216-1-0220 | 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. | 3299216_1.pdf | Software | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 41 / page 41 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0221 RFQX: RFQX-3299216-1-0221 | This test shall be possible to perform during exposure. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 41 / page 41 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0222 RFQX: RFQX-3299216-1-0222 | Reduced versions of test procedure II may be agreed and used during various tests. | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 41 / page 41 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.5.11 RFQX: RFQX-3299216-1-0223 | CVS40 §5.5 TC-05 Temperature cycle test Tmax.tes= +120°C, Tmin.test=-40°C Y | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 43 / page 43 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.5.12 RFQX: RFQX-3299216-1-0224 | CVS40 §5.6 TC-06 Thermal shock Y | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 43 / page 43 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.5.13 RFQX: RFQX-3299216-1-0225 | CVS40 §5.7 TC-07 Splash water test Y | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 43 / page 43 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.5.14 RFQX: RFQX-3299216-1-0226 | CVS40 §5.8 TC-08 Ice water / hot air shock test It is not allowed to use a snorkel to pass this test Y | 3299216_1.pdf | IT / backend | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 43 / page 43 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.5.15 RFQX: RFQX-3299216-1-0227 | CVS40 §5.9 TC-09 Leakage search test Y | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 43 / page 43 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.5.16 RFQX: RFQX-3299216-1-0228 | CVS40 §5.10 TC-10 Ingress protection The ECA shall also fulfil IP54 without mounted connectors. IP classes to test: IP6K6K, IP6K7, and IP6K9K Y | 3299216_1.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 43 / page 43 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| 10.5.17 RFQX: RFQX-3299216-1-0229 | CVS40 §5.11 TC-11 Corrosion in flowing mixed noxious gas N | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 43 / page 43 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.5.18 RFQX: RFQX-3299216-1-0230 | CVS40 §5.12 TC-12 Salt spray test Y | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 43 / page 43 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.5.19 RFQX: RFQX-3299216-1-0231 | CVS40 §5.13 TC-13 Dirt spray test TBD | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 43 / page 43 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.5.20 RFQX: RFQX-3299216-1-0232 | CVS40 §6.2 TM-01 Resonance search Y | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 43 / page 43 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.5.21 RFQX: RFQX-3299216-1-0233 | CVS40 §6.3 TM-02 Mechanical shock TBD | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 43 / page 43 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.5.22 RFQX: RFQX-3299216-1-0234 | CVS40 §6.4 TM-03 Random vibration and thermal cycle P1 Test 2 Y | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 43 / page 43 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.5.23 RFQX: RFQX-3299216-1-0235 | CVS40 §6.5 TM-04 Gravel bombardment and impact Y | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 43 / page 43 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.5.24 RFQX: RFQX-3299216-1-0236 | CVS40 §6.6 TM-05 External forces Y | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 43 / page 43 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.5.25 RFQX: RFQX-3299216-1-0237 | CVS40 §6.7 TM-06 Drop test – Free fall Y | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 43 / page 43 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.5.26 RFQX: RFQX-3299216-1-0238 | CVS40 §7.1 TL-01 Life length As per Chapter 8 Y | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 43 / page 43 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.5.27 RFQX: RFQX-3299216-1-0239 | CVS40 §7.2.1 TL-02 Power cycling test Y | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 43 / page 43 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.5.28 RFQX: RFQX-3299216-1-0240 | CVS40 §7.2.2 TL-03 Extended thermal shock air TBD | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 43 / page 43 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.5.29 RFQX: RFQX-3299216-1-0241 | CVS40 §7.2.3 TL-04 High temperature endurance test TBD | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 43 / page 43 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.5.30 RFQX: RFQX-3299216-1-0242 | CVS40 §7.2.4 TL-05 Endurance test / actuation TBD | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 43 / page 43 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.5.31 RFQX: RFQX-3299216-1-0243 | CVS40 §7.3 TL-06 Component specific test TBD | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 44 / page 44 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.5.32 RFQX: RFQX-3299216-1-0244 | CVS40 §7.4 TL-07 Ageing Y | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 44 / page 44 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.5.33 RFQX: RFQX-3299216-1-0245 | CVS40 §8.1 TS-01 Flammability In order to fulfil flammability demands, any plastic materials (i.e. tab headers) shall be made of self- extinguishing materials (i.e. UL94). Y | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 44 / page 44 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| 10.5.34 RFQX: RFQX-3299216-1-0246 | CVS40 §8.2 TS-02 UV resistance Datasheet sufficient Y | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 44 / page 44 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.5.35 RFQX: RFQX-3299216-1-0247 | CVS40 §8.3 TS-03 Chemical resistance Application method TBD Y | 3299216_1.pdf | Software | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 44 / page 44 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.5.36 RFQX: RFQX-3299216-1-0248 | CVS40 §8.4 TE-01 Isolation resistance and Dielectric strength tests N Exceptions and additional information to CVS41 [Y/N] | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 44 / page 44 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.6 RFQX: RFQX-3299216-1-0249 | CVS41 §4 Electrical loads Y | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 44 / page 44 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.6.1 RFQX: RFQX-3299216-1-0250 | CVS41 §4.1 TE-00 Operating Voltage Class A for ECU and communication. Class B for clutch actuation Y | 3299216_1.pdf | Hardware | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 44 / page 44 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.6.2 RFQX: RFQX-3299216-1-0251 | CVS41 §4.2 TE-01 Operating Voltage (Long-term overvoltage) Umax: 15 min, functional status Class B Y | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 44 / page 44 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.6.3 RFQX: RFQX-3299216-1-0252 | CVS41 §4.3 TE-02 Transient Overvoltage Y | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 44 / page 44 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.6.4 RFQX: RFQX-3299216-1-0253 | CVS41 §4.4 TE-03 Transient Undervoltage Y | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 44 / page 44 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.6.5 RFQX: RFQX-3299216-1-0254 | CVS41 §4.5 TE-04 Jump start Y | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 44 / page 44 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.6.6 RFQX: RFQX-3299216-1-0255 | CVS41 §4.6 TE-05 Load dump, test pulse 5b Y | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 44 / page 44 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-3299216-1-0256 RFQX: RFQX-3299216-1-0256 | tab headers) shall be made of self- extinguishing materials (i.e. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 44 / page 44 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| 10.7.14 RFQX: RFQX-3299216-1-0257 | CVS46 §4.6.6 Test LFM: Low Frequency Magnetic Y | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 47 / page 47 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.7.15 RFQX: RFQX-3299216-1-0258 | CVS46 §4.7 Test VCB CTE N | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 47 / page 47 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.7.16 RFQX: RFQX-3299216-1-0259 | CVS46 §4.8 Test VCB AN and VCB CP N | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 47 / page 47 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.7.17 RFQX: RFQX-3299216-1-0260 | CVS46 §4.9 Test C-VCB-VCA N | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 47 / page 47 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.7.18 RFQX: RFQX-3299216-1-0261 | CVS46 §4.10 Test TSUP VCB A N | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 47 / page 47 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.7.19 RFQX: RFQX-3299216-1-0262 | CVS46 §4.11 Test TSUP VCB B N | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 47 / page 47 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.7.20 RFQX: RFQX-3299216-1-0263 | CVS46 §4.12 Test VCB Surge N | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 47 / page 47 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.7.21 RFQX: RFQX-3299216-1-0264 | CVS46 §4.13 Test VCB Burst N | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 47 / page 47 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.7.22 RFQX: RFQX-3299216-1-0265 | CVS46 §4.14 Test VCB Charging mode N | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 47 / page 47 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.7.23 RFQX: RFQX-3299216-1-0266 | CVS46 §4.15 Test ESD: Immunity to electrostatic discharge (ESD) Y | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 47 / page 47 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.7.24 RFQX: RFQX-3299216-1-0267 | CVS46 §4.15.1 Test ESDD: Direct Discharge, Powered up Y | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 47 / page 47 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.7.25 RFQX: RFQX-3299216-1-0268 | CVS46 §4.15.2 Test ESDI: Indirect Discharge (Powered up) Y | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 47 / page 47 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.7.26 RFQX: RFQX-3299216-1-0269 | CVS46 §4.15.3 Test ESDH: ESD Handling, Component not energised Y | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 47 / page 47 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.7.27 RFQX: RFQX-3299216-1-0270 | CVS46 §5.1 Vehicle test ESD Traton performs Vehicle test, Traton may need support from supplier with any issues originating from the component. Y | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 47 / page 47 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.7.28 RFQX: RFQX-3299216-1-0271 | CVS46 §5.2 Vehicle test RE: Emitted interference of the complete vehicle Y | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 47 / page 47 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.7.29 RFQX: RFQX-3299216-1-0272 | CVS46 §5.2.1 Vehicle test RE: Protection of receivers outside the vehicle Y | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 47 / page 47 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.7.30 RFQX: RFQX-3299216-1-0273 | CVS46 §5.2.2 Vehicle test RE: Self interference Y | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 47 / page 47 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.7.31 RFQX: RFQX-3299216-1-0274 | CVS46 §5.3 Vehicle test charging: Vehicle in the AC charging mode N | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 47 / page 47 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.7.32 RFQX: RFQX-3299216-1-0275 | CVS46 §5.3.1 Vehicle test: AC charging Vehicle in AC charging mode N | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 47 / page 47 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.7.33 RFQX: RFQX-3299216-1-0276 | CVS46 §5.3.2 Vehicle test: DC charging: Vehicle in DC charging mode N | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 47 / page 47 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.7.34 RFQX: RFQX-3299216-1-0277 | CVS46 §5.4 Vehicle test RI: Immunity of vehicles to radiated fields Traton performs Vehicle test, Traton may need support from supplier with Y | 3299216_1.pdf | System | Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 47 / page 47 Pre-analysis Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 10.7.35 RFQX: RFQX-3299216-1-0278 | CVS46 §5.4.1 Vehicle test RI: External interference sources Y | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 47 / page 47 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-3299216-1-0279 RFQX: RFQX-3299216-1-0279 | P 1 Page 11 Functional safety The ECA is a part of a safety critical system and shall be handled as such. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 49 / page 49 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0280 RFQX: RFQX-3299216-1-0280 | The ECA shall therefore be developed and implemented in accordance with the objectives and requirements of ISO 26262 "Road vehicles - Functional Safety". | 3299216_1.pdf | Process / compliance | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 49 / page 49 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0281 RFQX: RFQX-3299216-1-0281 | The supplier shall analyse risks of individua l HW and SW components, mechanics, and any other technologies, independently of the scope of ISO 26262. | 3299216_1.pdf | Process / compliance | Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 49 / page 49 Pre-analysis Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0282 RFQX: RFQX-3299216-1-0282 | For this purpose possible causes must be systematically identified. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 49 / page 49 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0283 RFQX: RFQX-3299216-1-0283 | For these analyses at least the methods in ISO 26262 shall be applied. | 3299216_1.pdf | Process / compliance | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 49 / page 49 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| 12.2 RFQX: RFQX-3299216-1-0284 | Field test Traton will perform field tests with the unit mounted in trucks | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 50 / page 50 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 12.3 RFQX: RFQX-3299216-1-0285 | The supplier of the unit must write software to enable his own testing of the unit during development, production and on any claimed unit. | 3299216_1.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 50 / page 50 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0286 RFQX: RFQX-3299216-1-0286 | ID Verification methods 12.1 Conformance to Requirement Specification A1 The supplier must do conformance test of all external and internal I/O. | 3299216_1.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 50 / page 50 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0287 RFQX: RFQX-3299216-1-0287 | This test must verify that all internal and external I/O fulfils the requirements in this specification. | 3299216_1.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 50 / page 50 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0288 RFQX: RFQX-3299216-1-0288 | 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. | 3299216_1.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 50 / page 50 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0289 RFQX: RFQX-3299216-1-0289 | the suppler must carry out two full test rounds according to the Traton test requirements. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 50 / page 50 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0290 RFQX: RFQX-3299216-1-0290 | Additional tests initiated and performed by the supplier must be discussed with Traton. | 3299216_1.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 50 / page 50 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0291 RFQX: RFQX-3299216-1-0291 | A3 The supplier must test the connectors according to TB1787. | 3299216_1.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 50 / page 50 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0292 RFQX: RFQX-3299216-1-0292 | A4 The supplier must do EMC tests with the unit alone. | 3299216_1.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 50 / page 50 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0293 RFQX: RFQX-3299216-1-0293 | The supplier must certify the ECA according to UN ECE R10 (EMC), according to the latest revision with all amendments. | 3299216_1.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 50 / page 50 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0294 RFQX: RFQX-3299216-1-0294 | A5 The supplier must check that both prototypes and serial units fulfil the dimension requirement according to any relevant Traton supplied drawings. | 3299216_1.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 50 / page 50 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0295 RFQX: RFQX-3299216-1-0295 | 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. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page 3299216_1 > Page 50 / page 50 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0296 RFQX: RFQX-3299216-1-0296 | However, dividing sample phases into several generations must be agreed upon between Traton and the supplier. | 3299216_1.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 51 / page 51 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0297 RFQX: RFQX-3299216-1-0297 | All samples shall be functionally tested before sent to Traton. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 51 / page 51 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0298 RFQX: RFQX-3299216-1-0298 | Deviations shall be reported as a part of the sample delivery. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 51 / page 51 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0299 RFQX: RFQX-3299216-1-0299 | Dimensional checks shall be performed for B and C-samples prior to delivery to Traton. | 3299216_1.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 51 / page 51 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0300 RFQX: RFQX-3299216-1-0300 | The supplier must use the sample denominations requested by Traton. | 3299216_1.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 51 / page 51 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0301 RFQX: RFQX-3299216-1-0301 | Unless otherwise stated, valid version is the latest available as of 1st May 2026. | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 52 / page 52 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-3299216-1-0302 RFQX: RFQX-3299216-1-0302 | 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. | 3299216_1.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 57 / page 57 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| REQ 5.1 RFQX: RFQX-3299216-1-0303 | and 5.2. | 3299216_1.pdf | System | Non-mandatory wording; baseline inclusion not yet confirmed. Linked source table/diagram context was considered for interpretation. | Needs internal review. Confirm whether this should-level requirement is in the committed baseline. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Decide baseline inclusion internally, then issue an Accept/Partial position. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | NEEDS REVIEW | Analysis detailsSource section/page The full strokes should be performed within 180 ms, as specified in / page 57 Pre-analysis Non-mandatory wording; baseline inclusion not yet confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Internal baseline decision recorded. Engineering notes Complete internal review of wording and baseline scope. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0304 RFQX: RFQX-3299216-1-0304 | Between the two movements the actuator should remain in the fully disengaged position. | 3299216_1.pdf | System | Non-mandatory wording; baseline inclusion not yet confirmed. | Needs internal review. Confirm whether this should-level requirement is in the committed baseline. | Decide baseline inclusion internally, then issue an Accept/Partial position. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 57 / page 57 Pre-analysis Non-mandatory wording; baseline inclusion not yet confirmed. Assumptions Internal baseline decision recorded. Engineering notes Complete internal review of wording and baseline scope. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0305 RFQX: RFQX-3299216-1-0305 | After the complete engagement the actuator should remain in this position until the next disengagement is requested. | 3299216_1.pdf | System | Non-mandatory wording; baseline inclusion not yet confirmed. | Needs internal review. Confirm whether this should-level requirement is in the committed baseline. | Decide baseline inclusion internally, then issue an Accept/Partial position. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 57 / page 57 Pre-analysis Non-mandatory wording; baseline inclusion not yet confirmed. Assumptions Internal baseline decision recorded. Engineering notes Complete internal review of wording and baseline scope. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-3299216-1-0306 RFQX: RFQX-3299216-1-0306 | • 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. | 3299216_1.pdf | Software | Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3299216_1 > Page 59 / page 59 Pre-analysis Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| 18850001 RFQX: RFQX-3299216-1-0307 | , | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 59 / page 59 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 20000002 RFQX: RFQX-3299216-1-0308 | Normal operation, Class A | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 59 / page 59 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-3299216-1-0309 RFQX: RFQX-3299216-1-0309 | This needs to be checked with the first test run and if necessary the test cycle used in profile B needs to be changed. | 3299216_1.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3299216_1 > Page 61 / page 61 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS123-2-0001 RFQX: RFQX-CVS123-2-0001 | 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. | CVS123-2.pdf | Software | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS123-2 > Page 1 / page 1 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No supplier action - document reference / boilerplate. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS123-2-0002 RFQX: RFQX-CVS123-2-0002 | 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”. | CVS123-2.pdf | Process / compliance | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS123-2 > Page 1 / page 1 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS123-2-0003 RFQX: RFQX-CVS123-2-0003 | The User shall apply the latest version of this CVS123-2. | CVS123-2.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS123-2 > Page 1 / page 1 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_INFO 1 RFQX: RFQX-CVS123-2-0004 | This document specifies the method to perform software download using Software Update Variant 2 (SUV2). | CVS123-2.pdf | Software | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page 1 Scope / page 4 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 2 RFQX: RFQX-CVS123-2-0005 | The vehicle manufacturer implementation of the Authentication service (0x29) is defined in CVS31 and SecuredDataTransmission service (0x84) is defined in CVS32. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page 2 Overview 2.1 Summary / page 4 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 3 RFQX: RFQX-CVS123-2-0006 | While the requirements are applicable for programmable servers, some of the programming steps outlined in this specification (CommunicationControl and ControlDTCSetting) do not primarily target the programmable ECU, but the other ECUs on the same network which need to support the programming of the targeted ECU. | CVS123-2.pdf | Hardware | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 4 / page 4 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 4 RFQX: RFQX-CVS123-2-0007 | Support for programming as well as support for programming of other ECUs on the same network involves supporting what is referred to as pre- and post-programming steps. | CVS123-2.pdf | IT / backend | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 4 / page 4 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 5 RFQX: RFQX-CVS123-2-0008 | This specification is based on ISO14229-1:2020 and as such supports a “single server” approach to non-volatile memory programming with the intention to simplify client software development without significantly complicating server software development. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 4 / page 4 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 6 RFQX: RFQX-CVS123-2-0009 | With a single server objective, an ECU will appear to be programmable through communication with a single diagnostic server even if the ECU in fact implements two or more diagnostic servers – one in the boot loader and one in each application – and in reality will be programmed through communication with either one of them or both. | CVS123-2.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 4 / page 4 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 7 RFQX: RFQX-CVS123-2-0010 | 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. | CVS123-2.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 4 / page 4 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| SUV2_INFO 8 RFQX: RFQX-CVS123-2-0011 | 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. | CVS123-2.pdf | IT / backend | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 4 / page 4 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_INFO 9 RFQX: RFQX-CVS123-2-0012 | This specification targets ECUs, not clients. | CVS123-2.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 4 / page 4 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS123-2-0013 RFQX: RFQX-CVS123-2-0013 | Clients may prefer to implement programming support using other service parameter values or even another set of programming steps than | CVS123-2.pdf | Software | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS123-2 > Page 4 / page 4 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS123-2-0014 RFQX: RFQX-CVS123-2-0014 | For this reason, only the server is required to support the specified sequence. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS123-2 > Page 5 / page 5 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_INFO 10 RFQX: RFQX-CVS123-2-0015 | The target readers of this specification are ECU suppliers, which can be either internal or external in relation to the vehicle manufacturer. | CVS123-2.pdf | Hardware | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 2.2 Target Reader / page 5 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 11 RFQX: RFQX-CVS123-2-0016 | In both cases, whenever the term “ECU supplier” or just “supplier” is used in this specification it refers to the company and organization which is responsible for the implementation and delivery of the ECU according to the requirements in this specification. | CVS123-2.pdf | Hardware | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 5 / page 5 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 12 RFQX: RFQX-CVS123-2-0017 | The following documents are normative and indispensable for the application of this document: • ISO14229-1:2020, Road vehicles — Unified diagnostic services (UDS) — Part 1: Specification and requirements • CVS124, Traton Specification on Unified diagnostic services (UDS) requirements • CVS154, DSC Specification • CVS31, Authenticate 0x29 • CVS36, Secure ECU Parametrization • CVS32, SecuredDataTranmission 0x84 • CVS33, Entity Management Protocol (EMP) • CVS34, Entity Management Protocol (EMP) Basic Entity Definition | CVS123-2.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 2.3 Relation to other specifications Figure 1: Overview of relation between specifications / page 5 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 13 RFQX: RFQX-CVS123-2-0018 | Several terms that are used in this document but not defined in Table 1 are defined by ISO or in the document CVS124. | CVS123-2.pdf | Process / compliance | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 3 Terms, definitions and abbrevations 3.1 Definitions of terms / page 6 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS123-2-0019 RFQX: RFQX-CVS123-2-0019 | 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. | CVS123-2.pdf | Software | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 6 / page 6 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS123-2-0020 RFQX: RFQX-CVS123-2-0020 | It must be clearly separated from the application software. | CVS123-2.pdf | Software | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 6 / page 6 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS123-2-0021 RFQX: RFQX-CVS123-2-0021 | For this reason, it is located in a separate memory area and must also be erasable and programmable independently of the application software. | CVS123-2.pdf | Software | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 6 / page 6 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS123-2-0022 RFQX: RFQX-CVS123-2-0022 | Application software module Contains all vehicle functions required for the normal server operation. | CVS123-2.pdf | Software | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 6 / page 6 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS123-2-0023 RFQX: RFQX-CVS123-2-0023 | 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. | CVS123-2.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS123-2 > Page 6 / page 6 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| RFQX-CVS123-2-0024 RFQX: RFQX-CVS123-2-0024 | shall be implemented in the boot software code. | CVS123-2.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 6 / page 6 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS123-2-0025 RFQX: RFQX-CVS123-2-0025 | 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. | CVS123-2.pdf | Software | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 6 / page 6 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0051 RFQX: RFQX-CVS123-2-0026 | C2 Also referred to as “programming request” flag. | CVS123-2.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page More information on CVS124 / page 6 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS123-2-0027 RFQX: RFQX-CVS123-2-0027 | 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. | CVS123-2.pdf | Software | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 6 / page 6 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0051 RFQX: RFQX-CVS123-2-0028 | C3 Also referred to as “reprogrammed” flag. | CVS123-2.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page More information on CVS124 / page 6 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS123-2-0029 RFQX: RFQX-CVS123-2-0029 | The value of this variable may be used by the application to determine whether or not initialization is required. | CVS123-2.pdf | Software | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 6 / page 6 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS123-2-0030 RFQX: RFQX-CVS123-2-0030 | 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. | CVS123-2.pdf | Hardware | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 7 / page 7 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS123-2-0031 RFQX: RFQX-CVS123-2-0031 | 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 | CVS123-2.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS123-2 > Page 7 / page 7 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 15 RFQX: RFQX-CVS123-2-0032 | Requirements are prefixed “SUV2_REQ”. | CVS123-2.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 8 / page 8 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 16 RFQX: RFQX-CVS123-2-0033 | Similarly, informative text is prefixed “SUV2_INFO”. | CVS123-2.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 8 / page 8 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 1 RFQX: RFQX-CVS123-2-0034 | 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. | CVS123-2.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 4 General requirements / page 9 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RFQX-CVS123-2-0035 RFQX: RFQX-CVS123-2-0035 | 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. | CVS123-2.pdf | Software | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS123-2 > Page 9 / page 9 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 2 RFQX: RFQX-CVS123-2-0036 | All deviations from this specification shall be agreed with the applicable vehicle manufacturer(s). | CVS123-2.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 9 / page 9 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 3 RFQX: RFQX-CVS123-2-0037 | 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. | CVS123-2.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 9 / page 9 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 4 RFQX: RFQX-CVS123-2-0038 | If as a deviation with respect to | CVS123-2.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS123-2 > Page 9 / page 9 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 3 RFQX: RFQX-CVS123-2-0039 | an ECU will not support boot loader reprogramming, the boot loader SW shall be in a protected area of the memory. | CVS123-2.pdf | Hardware | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 9 / page 9 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS123-2-0040 RFQX: RFQX-CVS123-2-0040 | A SW or HW protection mechanism shall be used to protect the software from being accidentally erased or overwritten. | CVS123-2.pdf | Software | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS123-2 > Page 9 / page 9 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS123-2-0041 RFQX: RFQX-CVS123-2-0041 | If the microcontroller supports HW protection, this shall be used. | CVS123-2.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS123-2 > Page 9 / page 9 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 5 RFQX: RFQX-CVS123-2-0042 | 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. | CVS123-2.pdf | Software | Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 9 / page 9 Pre-analysis Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 6 RFQX: RFQX-CVS123-2-0043 | 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. | CVS123-2.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS123-2 > Page 9 / page 9 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 7 RFQX: RFQX-CVS123-2-0044 | Boot loader updating according to this specification shall be supported during development, from A-samples and onwards. | CVS123-2.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 9 / page 9 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_INFO 17 RFQX: RFQX-CVS123-2-0045 | Boot loaders need to be updated by the vehicle manufacturer on aftermarket workshop scenarios or at a test bench during component testing, when the ECU is mounted in a vehicle during system testing or in production to fix bugs. | CVS123-2.pdf | Hardware | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 9 / page 9 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 8 RFQX: RFQX-CVS123-2-0046 | 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. | CVS123-2.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 9 / page 9 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 9 RFQX: RFQX-CVS123-2-0047 | 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. | CVS123-2.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS123-2 > Page 9 / page 9 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 10 RFQX: RFQX-CVS123-2-0048 | 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. | CVS123-2.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 10 / page 10 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 11 RFQX: RFQX-CVS123-2-0049 | 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. | CVS123-2.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 4.1 Documentation requirements / page 10 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 12 RFQX: RFQX-CVS123-2-0050 | 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). | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 10 / page 10 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 13 RFQX: RFQX-CVS123-2-0051 | The supplier shall document the versioning concept for supplier specific DIDs. | CVS123-2.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 10 / page 10 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 14 RFQX: RFQX-CVS123-2-0052 | 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”. | CVS123-2.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 4.2 Software architecture requirements / page 10 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| RFQX-CVS123-2-0053 RFQX: RFQX-CVS123-2-0053 | When this module is programmed the parameter values in it shall override default parameter values persisted in the boot loader software module. | CVS123-2.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS123-2 > Page 10 / page 10 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_INFO 18 RFQX: RFQX-CVS123-2-0054 | The “boot parameter module” permits a generic bootloader to be an ECU application platform (ECU HW + boot loader software). | CVS123-2.pdf | Software | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 10 / page 10 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS123-2-0055 RFQX: RFQX-CVS123-2-0055 | 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. | CVS123-2.pdf | IT / backend | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS123-2 > Page 10 / page 10 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 15 RFQX: RFQX-CVS123-2-0056 | 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 | CVS123-2.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS123-2 > Page 10 / page 10 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| SUV2_INFO 19 RFQX: RFQX-CVS123-2-0057 | For definition of DID 0xF197 see CVS124. | CVS123-2.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 11 / page 11 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 16 RFQX: RFQX-CVS123-2-0058 | Default values for EOL parameters shall be implemented in a dedicated application data module, referred to as “EOL parameters module”. | CVS123-2.pdf | Software | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS123-2 > Page 11 / page 11 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 17 RFQX: RFQX-CVS123-2-0059 | The partitioning of the ECU software into modules shall be discussed and agreed with the vehicle manufacturer. | CVS123-2.pdf | Software | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 11 / page 11 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 18 RFQX: RFQX-CVS123-2-0060 | A joint use of program code for communication functions (com stack) by the application and the boot loader is not permitted. | CVS123-2.pdf | Software | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 11 / page 11 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 19 RFQX: RFQX-CVS123-2-0061 | A software released for integration test, production or service market shall be hashed so its integrity can be verified by the server. | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 4.3 Software distribution requirements / page 11 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 20 RFQX: RFQX-CVS123-2-0062 | Flash files delivered from the supplier shall never have to be modified by the vehicle manufacturer. | CVS123-2.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS123-2 > Page 11 / page 11 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_INFO 20 RFQX: RFQX-CVS123-2-0063 | It is within the scope of this specification that flash files delivered from the supplier can be encrypted by the vehicle manufacturer before storing in the vehicle manufacturer offboard database, but the server decryption of the received data will always restore it to servers memory into original data delivered by the supplier. | CVS123-2.pdf | Hardware | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 11 / page 11 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 182 RFQX: RFQX-CVS123-2-0064 | The supplier shall deliver the necessary information to verify the integrity of the flash files. | CVS123-2.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS123-2 > Page 11 / page 11 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_INFO 129 RFQX: RFQX-CVS123-2-0065 | 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. | CVS123-2.pdf | Interface | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 11 / page 11 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 21 RFQX: RFQX-CVS123-2-0066 | 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. | CVS123-2.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 11 / page 11 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_INFO 130 RFQX: RFQX-CVS123-2-0067 | 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. | CVS123-2.pdf | Software | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 11 / page 11 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 22 RFQX: RFQX-CVS123-2-0068 | 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. | CVS123-2.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 11 / page 11 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS123-2-0069 RFQX: RFQX-CVS123-2-0069 | Otherwise 0xF187 and 0xF188 shall be set to default values, see CVS124. | CVS123-2.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS123-2 > Page 11 / page 11 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 23 RFQX: RFQX-CVS123-2-0070 | Programmable servers shall support the full programming sequence described in this chapter. | CVS123-2.pdf | System | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 5 Detailed programming sequence / page 12 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 24 RFQX: RFQX-CVS123-2-0071 | Non-programmable servers shall support the pre-programming and post-programming steps of the programming sequence described in this chapter (phase 1 and 2). | CVS123-2.pdf | System | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 12 / page 12 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 25 RFQX: RFQX-CVS123-2-0072 | 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. | CVS123-2.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS123-2 > Page 12 / page 12 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_INFO 21 RFQX: RFQX-CVS123-2-0073 | If a valid application is present in the ECU, some of the services described in the programming sequence will be executed in the application. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 12 / page 12 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 22 RFQX: RFQX-CVS123-2-0074 | Each programming step will specify an addressing method (physical or functional), an SPRMIB (suppressPosRspMsgIndicationBit) bit value and other parameter values for the service(s) posted by the client. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 12 / page 12 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS123-2-0075 RFQX: RFQX-CVS123-2-0075 | 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. | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS123-2 > Page 12 / page 12 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_INFO 23 RFQX: RFQX-CVS123-2-0076 | The numbering of the programming sequence steps in this document generally has a well- defined relation to the numbering of the sequence steps in (ISO14229-1:2020). | CVS123-2.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 12 / page 12 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 24 RFQX: RFQX-CVS123-2-0077 | Programming phase #1 is defined to program a server (e.g., download of application software, application data or boot software). | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page E.g., (ISO14229-1:2020) / page 12 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 26 RFQX: RFQX-CVS123-2-0078 | 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. | CVS123-2.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS123-2 > Page 12 / page 12 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 27 RFQX: RFQX-CVS123-2-0079 | 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. | CVS123-2.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS123-2 > Page 12 / page 12 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_INFO 25 RFQX: RFQX-CVS123-2-0080 | For further information on the service details and programming messages structure regarding the SecuredDataTransmission (0x84) service, refer to CVS32. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 12 / page 12 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 26 RFQX: RFQX-CVS123-2-0081 | The sequence shown in the following figure shows the Pre-Programming step of phase #1. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 13 / page 13 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 27 RFQX: RFQX-CVS123-2-0082 | When this step is entered, the ECU is assumed to be in a state which enables it to receive UDS service requests. | CVS123-2.pdf | Software | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 5.1.1.1 P1Pre1: Init the data link / page 14 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 28 RFQX: RFQX-CVS123-2-0083 | For each server in the network, depending on whether an application has been successfully flashed before, it will run in application or boot mode. | CVS123-2.pdf | Software | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 14 / page 14 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 29 RFQX: RFQX-CVS123-2-0084 | The client posts a functionally addressed DiagnosticSessionControl (0x10) service request with sessionType equal to DefaultSession and the SPRMIB not set. | CVS123-2.pdf | Software | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 14 / page 14 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 30 RFQX: RFQX-CVS123-2-0085 | If servers which support wake-up on CAN are not awake before, this request causes them to wake-up. | CVS123-2.pdf | Interface | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 14 / page 14 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 31 RFQX: RFQX-CVS123-2-0086 | All servers available on the network and their diagnostic addresses are identified from the positive responses to this request. | CVS123-2.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 14 / page 14 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 32 RFQX: RFQX-CVS123-2-0087 | The client then posts physically or functionally addressed ReadDataByIdentifier (0x22) service requests to collect additional identification data from each identified server. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 14 / page 14 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 33 RFQX: RFQX-CVS123-2-0088 | The client post physically addressed RoutineControl (0x31) (EMP) service request with SPRMIB not set and operation-type set to Get (0x01). | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page 5.1.1.2 P1PreA: EMP (Get entities) / page 14 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 34 RFQX: RFQX-CVS123-2-0089 | In this step, it is client dependent if and what cyber security entities are relevant to be read for performing the remaining steps of the sequence. | CVS123-2.pdf | Cybersecurity | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 14 / page 14 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 35 RFQX: RFQX-CVS123-2-0090 | 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. | CVS123-2.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 14 / page 14 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 36 RFQX: RFQX-CVS123-2-0091 | For reference on EMP control routine, see CVS33. | CVS123-2.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 14 / page 14 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 37 RFQX: RFQX-CVS123-2-0092 | The client post physically addressed RoutineControl (0x31) (EMP) service request with SPRMIB not set and operation-type set to Set (0x00). | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page 5.1.1.3 P1PreB: EMP (Set entities) / page 14 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 38 RFQX: RFQX-CVS123-2-0093 | In this step, the client will set a new SDSC entity, and it is client dependent if and what other entities are relevant to be set/update for performing the remaining steps of the sequence. | CVS123-2.pdf | IT / backend | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 14 / page 14 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 39 RFQX: RFQX-CVS123-2-0094 | 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. | CVS123-2.pdf | IT / backend | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 14 / page 14 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS123-2-0095 RFQX: RFQX-CVS123-2-0095 | Alternatively, it may be a client strategy to always update certain entities prior to a software update. | CVS123-2.pdf | Software | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS123-2 > Page 14 / page 14 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 40 RFQX: RFQX-CVS123-2-0096 | For reference on EMP control routine, see CVS33. | CVS123-2.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 14 / page 14 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 41 RFQX: RFQX-CVS123-2-0097 | The client post physically addressed authentication sequence based on CVS31 with SPRMIB not set. | CVS123-2.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page 5.1.1.4 P1PreC: Authentication Sequence / page 14 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 42 RFQX: RFQX-CVS123-2-0098 | The client posts a functionally addressed DiagnosticSessionControl (0x10) service request with sessionType equal to extended diagnostic session and the SPRMIB set. | CVS123-2.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page 5.1.1.5 P1Pre2: Diagnostic Session Control (extended Diagnostic Session) / page 15 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 43 RFQX: RFQX-CVS123-2-0099 | From this point, onwards (throughout the entire programming sequence) the client posts functionally addressed TesterPresent (0x3E) service requests at regular intervals, with the SPRMIB set, with the purpose to make the server(s) stay in the currently active non-default session and maintain its authenticated state. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 15 / page 15 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 44 RFQX: RFQX-CVS123-2-0100 | The client disables the setting of DTCs in each server by posting a functionally addressed ControlDTCSetting (0x85) service request with the sub-function parameter DTCSettingType set to off and the SPRMIB set. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page 5.1.1.6 P1Pre5: Control DTC Setting (DTC setting type = off) / page 15 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 45 RFQX: RFQX-CVS123-2-0101 | If the server is executing in the boot loader it will accept the request without performing any action, as DTCs are already disabled (DTC setting not supported by boot loader). | CVS123-2.pdf | IT / backend | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 15 / page 15 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 46 RFQX: RFQX-CVS123-2-0102 | The client disables the transmission of non-diagnostic messages by posting a functionally addressed CommunicationControl (0x28) service request with parameter controlType set to enableRxAndDisableTx, parameter communicationType set to normalCommunicationMessages and SPRMIB set. | CVS123-2.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page 5.1.1.7 P1Pre7: Communication Control (disable non-diagnostic communication) / page 15 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 47 RFQX: RFQX-CVS123-2-0103 | If the server is executing in the boot loader when this service request is received no action will be performed by the server as non-diagnostic messages are already disabled. | CVS123-2.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 15 / page 15 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 48 RFQX: RFQX-CVS123-2-0104 | Link control is only applicable to standalone programming (i.e., when the ECU is not mounted in the vehicle) at vehicle manufacturer premises when no application has been programmed by the supplier, communication network permits baud rate switch (e.g CAN) and only if performance requirement cannot be met without using this service. | CVS123-2.pdf | Software | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page 5.1.1.8 P1Pre9: Link Control (verify and/or switch baud rate) / page 15 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 49 RFQX: RFQX-CVS123-2-0105 | The client posts a physically addressed LinkControl (0x87) service request with parameter linkControlType set to verifyBaudrateTransitionWithFixedParameter, SPRMIB not set and linkControlModeIdentifier set to desired baud rate. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 15 / page 15 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 50 RFQX: RFQX-CVS123-2-0106 | After reception of a positive response message the client posts a physically addressed LinkControl (0x87) service request with sub-function parameter linkControlType set to transitionMode and the SPRMIB set. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 15 / page 15 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 51 RFQX: RFQX-CVS123-2-0107 | The client will then switch to the new baud rate and re-establish communication with the ECU considering the maximum specified time it will take for the server to start responding to the newly selected baud rate. | CVS123-2.pdf | Hardware | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 15 / page 15 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 52 RFQX: RFQX-CVS123-2-0108 | 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. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 15 / page 15 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 53 RFQX: RFQX-CVS123-2-0109 | The sequence in Figure 3 shows the programming step of phase #1. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.1.2 Programming step of phase #1 – Download of application software and data / page 16 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 28 RFQX: RFQX-CVS123-2-0110 | 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). | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 16 / page 16 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_INFO 54 RFQX: RFQX-CVS123-2-0111 | The information to verify integrity of the software is contained in software data security container (SDSC), which is transmitted in P1PreB step. | CVS123-2.pdf | Cybersecurity | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 16 / page 16 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 29 RFQX: RFQX-CVS123-2-0112 | If the SW to be updated is encrypted, decryption keys shall be available to the server before step P1Pro9. | CVS123-2.pdf | IT / backend | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS123-2 > Page 16 / page 16 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_INFO 55 RFQX: RFQX-CVS123-2-0113 | If SDSC dictates decryption, the decryption keys are contained in software data security container (SDSC) which is transmitted in P1PreB step. | CVS123-2.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 16 / page 16 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 30 RFQX: RFQX-CVS123-2-0114 | 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. | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 16 / page 16 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_INFO 56 RFQX: RFQX-CVS123-2-0115 | The client posts a physically addressed DiagnosticSessionControl (0x10) service request with sub-function parameter diagnosticSessionType set to ProgrammingSession and the SPRMIB not set. | CVS123-2.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 5.1.2.1 P1Pro1: Diagnostic Session Control (Programming Session) / page 17 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 57 RFQX: RFQX-CVS123-2-0116 | If CommunicationControl has not been previously called in the Extended Diagnostic Session the server rejects the request with negative response code NRC 0x22 (conditionsNotCorrect). | CVS123-2.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 17 / page 17 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 58 RFQX: RFQX-CVS123-2-0117 | Implementation hint: If the server is executing the application the server sets a “programming request” flag (C2, see section Boot software session requirements). | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 17 / page 17 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 59 RFQX: RFQX-CVS123-2-0118 | If the server is executing the application the server responds to the request with one or more negative response codes NRC 0x78 (requestCorrectlyReceived-ResponsePending) and triggers a server restart. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 17 / page 17 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 60 RFQX: RFQX-CVS123-2-0119 | The boot manager notes the programming request and starts the boot loader. | CVS123-2.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 17 / page 17 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 61 RFQX: RFQX-CVS123-2-0120 | Implementation hint: The boot manager recognizes the programming request by checking the “programming request” flag (C2). | CVS123-2.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 17 / page 17 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 62 RFQX: RFQX-CVS123-2-0121 | Implementation hint: The boot manager or the boot loader resets the “programming request” flag (C2). | CVS123-2.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 17 / page 17 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 63 RFQX: RFQX-CVS123-2-0122 | Finally, the boot loader sends a positive response. | CVS123-2.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 17 / page 17 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 64 RFQX: RFQX-CVS123-2-0123 | The client post physically addressed authentication sequence based on Authenticate 0x29 with SPRMIB not set. | CVS123-2.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page 5.1.2.2 P1ProB: Authentication / page 17 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 65 RFQX: RFQX-CVS123-2-0124 | The client posts a physically addressed RoutineControl (0x31) (eraseMemory) service request with a memory start address and a memory size value set for parameter RoutineControlOptionRecord and the SPRMIB not set. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page 5.1.2.3 P1Pro6: Routine Control (erase Memory) / page 17 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 66 RFQX: RFQX-CVS123-2-0125 | Implementation hint: The server resets the “application valid” flag (C1, see CVS124 | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 17 / page 17 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0051 RFQX: RFQX-CVS123-2-0126 | ) before the erase process starts, to ensure that the server will start in boot loader mode if the programming gets interrupted or if the programming is faulty. | CVS123-2.pdf | IT / backend | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 17 / page 17 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 67 RFQX: RFQX-CVS123-2-0127 | The server erases the applicable SW identification DIDs, see Erase Memory routine requirements in 8.3. | CVS123-2.pdf | Hardware | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 17 / page 17 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 68 RFQX: RFQX-CVS123-2-0128 | The client posts physically addressed RequestDownload (0x34) service requests with the SPRMIB not set. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page 5.1.2.4 P1Pro9.1: Request Download / page 17 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 69 RFQX: RFQX-CVS123-2-0129 | If the boot software module is updated in this step, DID 0xF180 (bootSoftwareIdentificationDataIdentifier) will be automatically updated as well as this ID will be implemented as part of the boot software module. | CVS123-2.pdf | Software | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page 5.1.2.5 P1Pro9.2: Sequences of Transfer Data and Request Transfer Exit / page 18 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 70 RFQX: RFQX-CVS123-2-0130 | If the application software module is updated in this step, DID 0xF181 (applicationSoftwareIdentificationDataIdentifier) will be automatically updated as well as this ID will be implemented as part of the application software module. | CVS123-2.pdf | Software | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 18 / page 18 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 71 RFQX: RFQX-CVS123-2-0131 | If the application data module is updated in this step DID 0xF182 (applicationDataIdentificationDataIdentifier) will be automatically updated as well as this ID will be implemented as part of the application data module. | CVS123-2.pdf | Software | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 18 / page 18 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 72 RFQX: RFQX-CVS123-2-0132 | If the application software module is updated in this step, DID 0xF187 (vehicleManufacturerSparePartNumberDataIdentifier) will be automatically updated as well as this ID will be implemented as part of the application data module. | CVS123-2.pdf | Software | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 18 / page 18 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 73 RFQX: RFQX-CVS123-2-0133 | If the application software module is updated in this step, DID 0xF188 (vehicleManufacturerECUSoftwareNumberDataIdentifier) will be automatically updated as well as this ID will be implemented as part of the application software module. | CVS123-2.pdf | Software | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 18 / page 18 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 74 RFQX: RFQX-CVS123-2-0134 | It is client specific if P1Pro10 will be sent as part of programming phase #1. | CVS123-2.pdf | Hardware | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page 5.1.2.6 P1Pro10: Routine Control (Check Memory Block) / page 18 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 75 RFQX: RFQX-CVS123-2-0135 | This routineIdentifier is supported to allow process improvement during the software update since it allows client to react as soon as a corruption is identified in the transferred module data. | CVS123-2.pdf | Software | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 18 / page 18 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 76 RFQX: RFQX-CVS123-2-0136 | The client posts a physically addressed RoutineControl (0x31) (checkMemory) service request with the SPRMIB not set. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 18 / page 18 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 77 RFQX: RFQX-CVS123-2-0137 | According to | CVS123-2.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 18 / page 18 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 99 RFQX: RFQX-CVS123-2-0138 | , this routineIdentifier allows the server to verify if the transferred data is correct (has not been corrupted) by calculating a checksum and comparing this checksum with the checksum transferred as part of the data (via transferData). | CVS123-2.pdf | IT / backend | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 18 / page 18 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 78 RFQX: RFQX-CVS123-2-0139 | The response of this routineIdentifier allows the client to identify if the specific transferred block is corrupted. | CVS123-2.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 18 / page 18 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 79 RFQX: RFQX-CVS123-2-0140 | According to | CVS123-2.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 18 / page 18 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 119 RFQX: RFQX-CVS123-2-0141 | , as a part of the consistency check the server verifies the integrity of the programmed software. | CVS123-2.pdf | Software | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 18 / page 18 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 80 RFQX: RFQX-CVS123-2-0142 | According to | CVS123-2.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 18 / page 18 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 126 RFQX: RFQX-CVS123-2-0143 | , the check on consistency can produce a positive result only 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. | CVS123-2.pdf | Software | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 18 / page 18 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 81 RFQX: RFQX-CVS123-2-0144 | As part of the routine checks, the server will use the information defined in SDSC to perform the software verification, see 9.2. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 19 / page 19 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 82 RFQX: RFQX-CVS123-2-0145 | 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. | CVS123-2.pdf | Hardware | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 19 / page 19 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 87 RFQX: RFQX-CVS123-2-0146 | The sequence shown in the following figure shows the post-programming step of phase #1. | CVS123-2.pdf | IT / backend | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 5.1.3 Post-Programming step of phase #1 — Re-synchronization of vehicle network / page 19 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 88 RFQX: RFQX-CVS123-2-0147 | After the consistency check (independent of the result), the client initiates a server restart by posting a physically addressed ECUReset (0x11) (hardReset) service request with the SPRMIB not set. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page Figure 4: Programming phase #1 – Post-Programming step 5.1.3.1 P1Pos1: ECU Reset (hard reset) / page 19 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 89 RFQX: RFQX-CVS123-2-0148 | The server responds positively to the request before the reset takes place. | CVS123-2.pdf | IT / backend | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 19 / page 19 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 90 RFQX: RFQX-CVS123-2-0149 | After reset, if the ECU hardware/software is deemed to be consistent and all software and data identification DIDs in CVS124 which have been flashed or written as part of the programming | CVS123-2.pdf | Software | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 19 / page 19 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 91 RFQX: RFQX-CVS123-2-0150 | The application reads and applies the boot parameter values from the boot parameter module. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 20 / page 20 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 92 RFQX: RFQX-CVS123-2-0151 | Implementation hint: The boot manager checks the “application valid” flag (C1) to see if the ECU hardware/software is consistent and all software and data identification DIDs in CVS124 contain non-default values. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 20 / page 20 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 93 RFQX: RFQX-CVS123-2-0152 | If the application was started, it checks if application initialization is required. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 20 / page 20 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS123-2-0153 RFQX: RFQX-CVS123-2-0153 | 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. | CVS123-2.pdf | Hardware | Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS123-2 > Page 20 / page 20 Pre-analysis Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_INFO 94 RFQX: RFQX-CVS123-2-0154 | Implementation hint: The ECU application checks the reprogrammed flag (C3, see programming step P1Pro11) to see if application initialization is required. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 20 / page 20 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_INFO 95 RFQX: RFQX-CVS123-2-0155 | Implementation hint: If the “application valid” flag (C1) indicates that the ECU application state is not valid, the boot manager will execute the boot loader. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 20 / page 20 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 96 RFQX: RFQX-CVS123-2-0156 | If the boot loader is executed and a boot parameter module exists, the boot loader reads and applies the boot parameter values from this module. | CVS123-2.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 20 / page 20 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 97 RFQX: RFQX-CVS123-2-0157 | According to | CVS123-2.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 20 / page 20 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 27 RFQX: RFQX-CVS123-2-0158 | , the client post physically addressed authentication (0x29) request with subfunction deAuthenticate (0x00) based on CVS31 with SPRMIB not set. | CVS123-2.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS123-2 > Page 20 / page 20 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 83 RFQX: RFQX-CVS123-2-0159 | The client post physically addressed RoutineControl (0x31) (EMP) service request with SPRMIB not set and operation-type set to Set (0x00). | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page 5.1.3.3 P1PosB: EMP (Set entities) / page 20 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 84 RFQX: RFQX-CVS123-2-0160 | In this step, it is client dependent if and what entities are relevant to be set after updating the software. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 20 / page 20 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 85 RFQX: RFQX-CVS123-2-0161 | 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. | CVS123-2.pdf | Software | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 20 / page 20 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_INFO 86 RFQX: RFQX-CVS123-2-0162 | For reference on EMP control routine, see CVS33. | CVS123-2.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 20 / page 20 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 99 RFQX: RFQX-CVS123-2-0163 | The programming phase #2 (server configuration or also known as parametrization) as defined in ISO 14229-2 is defined in CVS36. | CVS123-2.pdf | IT / backend | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page 5.1.4 Programming Phase #2 / page 20 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 33 RFQX: RFQX-CVS123-2-0164 | ECUs that will be programmed stand-alone at the vehicle manufacturer over DoCAN shall support 1 Mbit transfer speed. | CVS123-2.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 6 Server reprogramming requirements 6.1 Requirements for servers to support programming / page 21 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 34 RFQX: RFQX-CVS123-2-0165 | Whether or not the ECU shall support stand-alone programming at the vehicle manufacturer premises shall be discussed and agreed with the vehicle manufacturer. | CVS123-2.pdf | Hardware | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 21 / page 21 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 35 RFQX: RFQX-CVS123-2-0166 | A server that is running in the application shall respond with the same diagnostic address after a switch to boot. | CVS123-2.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS123-2 > Page 21 / page 21 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 36 RFQX: RFQX-CVS123-2-0167 | 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. | CVS123-2.pdf | Software | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 21 / page 21 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 37 RFQX: RFQX-CVS123-2-0168 | Application software and application data modules shall be programmable in any order. | CVS123-2.pdf | Software | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS123-2 > Page 21 / page 21 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 38 RFQX: RFQX-CVS123-2-0169 | The server shall be able to update an individual module independently from any other module. | CVS123-2.pdf | IT / backend | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS123-2 > Page 21 / page 21 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_INFO 100 RFQX: RFQX-CVS123-2-0170 | This is to keep the programming time to a minimum. | CVS123-2.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 21 / page 21 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 39 RFQX: RFQX-CVS123-2-0171 | If the performance requirements | CVS123-2.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS123-2 > Page 21 / page 21 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 62 RFQX: RFQX-CVS123-2-0172 | or | CVS123-2.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 21 / page 21 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 63 RFQX: RFQX-CVS123-2-0173 | cannot be met, a compression method shall be implemented. | CVS123-2.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 21 / page 21 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_INFO 101 RFQX: RFQX-CVS123-2-0174 | This is to shorten the time for the data transfer from the tester to the ECU to be programmed. | CVS123-2.pdf | Hardware | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 21 / page 21 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 40 RFQX: RFQX-CVS123-2-0175 | 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. | CVS123-2.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS123-2 > Page 21 / page 21 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 41 RFQX: RFQX-CVS123-2-0176 | The use of alternative compression/decompression algorithms shall be agreed with the vehicle manufacturer. | CVS123-2.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 21 / page 21 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 42 RFQX: RFQX-CVS123-2-0177 | It shall be possible to program the same software version repeatedly. | CVS123-2.pdf | Software | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS123-2 > Page 21 / page 21 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 43 RFQX: RFQX-CVS123-2-0178 | 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. | CVS123-2.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 21 / page 21 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 44 RFQX: RFQX-CVS123-2-0179 | 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. | CVS123-2.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 21 / page 21 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_INFO 102 RFQX: RFQX-CVS123-2-0180 | In case of e.g., flash interruption resetting the DIDs to default values will enable the client to identify the ECU as not having a valid application. | CVS123-2.pdf | Software | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 21 / page 21 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 45 RFQX: RFQX-CVS123-2-0181 | 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. | CVS123-2.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 21 / page 21 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS123-2-0182 RFQX: RFQX-CVS123-2-0182 | 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. | CVS123-2.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS123-2 > Page 21 / page 21 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS123-2-0183 RFQX: RFQX-CVS123-2-0183 | 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. | CVS123-2.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS123-2 > Page 21 / page 21 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 46 RFQX: RFQX-CVS123-2-0184 | After reprogramming, the application shall store DIDs F1AB, F1AA, F1A9. | CVS123-2.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS123-2 > Page 22 / page 22 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 47 RFQX: RFQX-CVS123-2-0185 | The technical implementation of the programming preconditions shall be agreed between the supplier and the vehicle manufacturer. | CVS123-2.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 22 / page 22 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 48 RFQX: RFQX-CVS123-2-0186 | A programmable server shall guarantee re-programmability within the normal operating voltage range specified by [11] for 24V systems or [12] for 12V systems. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 22 / page 22 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 49 RFQX: RFQX-CVS123-2-0187 | 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. | CVS123-2.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 22 / page 22 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 50 RFQX: RFQX-CVS123-2-0188 | The server shall guarantee re-programmability in the event of error conditions during the programming process regardless of cause. | CVS123-2.pdf | Software | Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 6.1.1 Boot software description and requirements 6.1.1.1 Boot software general requirements / page 22 Pre-analysis Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RFQX-CVS123-2-0189 RFQX: RFQX-CVS123-2-0189 | The causes specified in (ISO14229-1:2020) shall be regarded as examples. | CVS123-2.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS123-2 > Page 22 / page 22 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 51 RFQX: RFQX-CVS123-2-0190 | 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. | CVS123-2.pdf | Software | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 22 / page 22 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_INFO 103 RFQX: RFQX-CVS123-2-0191 | This means, for example, that loss of application server specific diagnostic address, -bitrate or - system name as a result of a failure during boot parameter module programming in the workshop is not acceptable. | CVS123-2.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 22 / page 22 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 52 RFQX: RFQX-CVS123-2-0192 | Diagnostic services support shall be as per CVS124. | CVS123-2.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 6.1.1.2 Boot software session requirements / page 22 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| SUV2_REQ 53 RFQX: RFQX-CVS123-2-0193 | Additionally, the services specified in Table 3 shall be supported. | CVS123-2.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 22 / page 22 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 54 RFQX: RFQX-CVS123-2-0194 | In case of divergences between CVS124 and Table 3, this document takes precedence. | CVS123-2.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 22 / page 22 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 104 RFQX: RFQX-CVS123-2-0195 | For a server, it is the combination of services support in CVS124 and Table 3 that will constitute the complete picture of supported services. | CVS123-2.pdf | IT / backend | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 22 / page 22 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 55 RFQX: RFQX-CVS123-2-0196 | ECU identification data support shall be as per CVS124. | CVS123-2.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page Non-Def = Any other session than default diagnostic session 6.1.1.3 ECU Identification Data / page 23 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| SUV2_REQ 62 RFQX: RFQX-CVS123-2-0197 | 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). | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 6.1.1.4 Performance requirements / page 23 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_INFO 106 RFQX: RFQX-CVS123-2-0198 | 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. | CVS123-2.pdf | Software | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 23 / page 23 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 63 RFQX: RFQX-CVS123-2-0199 | 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). | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 23 / page 23 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 64 RFQX: RFQX-CVS123-2-0200 | The server shall support the routines specified in Table 4. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 6.1.1.4.1 Server routine access / page 23 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 65 RFQX: RFQX-CVS123-2-0201 | 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. | CVS123-2.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 7 Diagnostic service requirements 7.1 RequestDownload (0x34) Service / page 24 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_INFO 107 RFQX: RFQX-CVS123-2-0202 | 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. | CVS123-2.pdf | Hardware | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 24 / page 24 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 66 RFQX: RFQX-CVS123-2-0203 | 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). | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 24 / page 24 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 67 RFQX: RFQX-CVS123-2-0204 | 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. | CVS123-2.pdf | Software | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS123-2 > Page 24 / page 24 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 68 RFQX: RFQX-CVS123-2-0205 | 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 | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 24 / page 24 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RFQX-CVS123-2-0206 RFQX: RFQX-CVS123-2-0206 | (requestSequenceError) and shall accept programming to proceed from the state at which it was executing before this non-permitted service was requested. | CVS123-2.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS123-2 > Page 25 / page 25 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 69 RFQX: RFQX-CVS123-2-0207 | For each received RequestDownload request, the server shall check if there is a VerificationEntry match in SDSC. | CVS123-2.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 25 / page 25 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_INFO 108 RFQX: RFQX-CVS123-2-0208 | For more information on SDSC, see chapter 9. | CVS123-2.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 25 / page 25 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 71 RFQX: RFQX-CVS123-2-0209 | 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. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 25 / page 25 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_INFO 109 RFQX: RFQX-CVS123-2-0210 | If an encryptionEntry match is found, see chapter 9.3. | CVS123-2.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 25 / page 25 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 190 RFQX: RFQX-CVS123-2-0211 | The server shall not execute the new software until it can be verified using routine 0xFF01. | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 25 / page 25 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_INFO 150 RFQX: RFQX-CVS123-2-0212 | The software to be received over TransferData (0x36) is to be considered NOT_OK until a verification takes place. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 25 / page 25 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 72 RFQX: RFQX-CVS123-2-0213 | The server shall support service request formatted according to Table 5. | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 7.1.1 Request / page 25 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 73 RFQX: RFQX-CVS123-2-0214 | The server shall support service positive response formatted according to Table 6. | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 7.1.2 Positive Response / page 26 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 74 RFQX: RFQX-CVS123-2-0215 | The server shall support service negative response as per ISO14229-1:2020. | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page #4 maxNumberOfBlockLength[] = [ byte #1 (MSB) byte #2 ] M 0x0000 – 0xFFFF 7.1.3 Negative Response / page 26 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 165 RFQX: RFQX-CVS123-2-0216 | In case a software is encrypted, the server shall decrypt the software before decompression and software hash comparison verification are performed. | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 7.1.4 Service 0x34 Parameters / page 26 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 166 RFQX: RFQX-CVS123-2-0217 | In case a software is compressed, the server shall decompress the software before software hash comparison verification is performed. | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 26 / page 26 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 167 RFQX: RFQX-CVS123-2-0218 | The server shall verify the software hash after decryption and/or decompression are performed. | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 26 / page 26 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_INFO 137 RFQX: RFQX-CVS123-2-0219 | Considering that hashing, compression and encryption methods were used prior to transfer a software to the server, the server will decrypt, decompress, and perform software hashing comparison verification in this respective order. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 26 / page 26 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 75 RFQX: RFQX-CVS123-2-0220 | The server shall support parameter dataFormatIdentifier formatted according to Table 7. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 7.1.4.1 Parameter dataFormatIdentifier / page 26 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 80 RFQX: RFQX-CVS123-2-0221 | Negative Response | CVS123-2.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 7.2.3 Negative Response / page 27 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 76 RFQX: RFQX-CVS123-2-0222 | The server shall support parameter addressAndLengthFormatIdentifier formatted according to Table 8. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 7.1.4.2 Parameter addressAndLengthFormatIdentifier / page 27 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 77 RFQX: RFQX-CVS123-2-0223 | 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 The server shall support parameter lengthFormatIdentifier formatted according to Table 9. | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 27 / page 27 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 78 RFQX: RFQX-CVS123-2-0224 | The server shall support request formatted according to ISO14229-1:2020. | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page M 0 7.2 TransferData (0x36) Service 7.2.1 Request / page 27 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 79 RFQX: RFQX-CVS123-2-0225 | The server shall support positive response formatted according to ISO14229-1:2020. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 7.2.2 Positive Response / page 27 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 81 RFQX: RFQX-CVS123-2-0226 | If for any reason an error occurs during decryption of data, the server shall return NRC 0x10. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 27 / page 27 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 82 RFQX: RFQX-CVS123-2-0227 | The server shall support parameter blockSequenceCounter formatted according to ISO14229-1:2020. | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 7.2.4 Service 0x36 Parameters 7.2.4.1 Parameter blockSequenceCounter / page 27 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 83 RFQX: RFQX-CVS123-2-0228 | The server shall support parameter transferRequestParameterRecord formatted according to ISO14229-1:2020. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 7.2.4.2 Parameter transferRequestParameterRecord / page 28 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 84 RFQX: RFQX-CVS123-2-0229 | The server shall support request formatted according to Table 10. | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 7.3 RequestTransferExit (0x37) Service 7.3.1 Request / page 28 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 85 RFQX: RFQX-CVS123-2-0230 | The server shall support positive response formatted according to Table 11. | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page Table 10: Service 0x37 Request Format Byte No Description Cvt Byte Value 1 RequestTransferExit Request SID M 0x37 7.3.2 Positive Response / page 28 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 86 RFQX: RFQX-CVS123-2-0231 | 7.3.4 Service 0x37 Parameters 7.3.4.1 Parameter transferRequestParameterRecord | CVS123-2.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 28 / page 28 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 87 RFQX: RFQX-CVS123-2-0232 | The server shall not support transferRequestParameterRecord parameter. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 28 / page 28 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 88 RFQX: RFQX-CVS123-2-0233 | The server shall not support transferResponseParameterRecord parameter. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 7.3.4.2 Parameter transferResponseParameterRecord / page 28 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 89 RFQX: RFQX-CVS123-2-0234 | The server shall support service 0x84 according to CVS32. | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 7.4 SecuredDataTranmission (0x84) Service / page 28 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 90 RFQX: RFQX-CVS123-2-0235 | The server shall support request formatted according to ISO14229-1:2020. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 7.4.1 Request / page 28 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 92 RFQX: RFQX-CVS123-2-0236 | Negative Response | CVS123-2.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 7.4.3 Negative Response / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 91 RFQX: RFQX-CVS123-2-0237 | The server shall support positive response formatted according to ISO14229-1:2020. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 7.4.2 Positive Response / page 29 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 93 RFQX: RFQX-CVS123-2-0238 | The server shall support negative response codes according to CVS32. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 29 / page 29 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 94 RFQX: RFQX-CVS123-2-0239 | The server shall support parameter Administrative Parameter formatted according to ISO14229-1:2020. | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 7.4.4 Service 0x84 Parameters 7.4.4.1 Parameter Administrative Parameter / page 29 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 95 RFQX: RFQX-CVS123-2-0240 | The server shall support parameter Signature/Encryption Calculation (SIGENCRYPT) according to CVS32. | CVS123-2.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 7.4.4.2 Parameter Signature/Encryption Calculation (SIGENCRYPT) / page 29 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 96 RFQX: RFQX-CVS123-2-0241 | The server shall support parameter Anti-replay Counter (ANTIREPLAYCNT) according to CVS32. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 7.4.4.3 Parameter Anti-replay Counter (ANTIREPLAYCNT) / page 29 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 97 RFQX: RFQX-CVS123-2-0242 | The server shall support the routine in the diagnosticSession according to Table 12. | CVS123-2.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 8 Diagnostic Routine Identifier Requirements 8.1 Routine Session and routineControlSupport 8.1.1 Routine Session Support / page 29 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 98 RFQX: RFQX-CVS123-2-0243 | The server shall support the routineControlType according to Table 13. | CVS123-2.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page Non-Def = Any other session than default diagnostic session 8.1.2 Routine routineControlType Support / page 30 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 181 RFQX: RFQX-CVS123-2-0244 | 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 The server shall implement diagnostic safe state, as per CVS124, as preconditions to the routines according to Table 14. | CVS123-2.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS123-2 > Page 30 / page 30 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_INFO 110 RFQX: RFQX-CVS123-2-0245 | Table 14: Routine support for Safe State Conditions RID Name Safe State 0x2202 Check Memory Block M 0xFF00 EraseMemory M - 0xFF01 CheckProgrammingDependencies M M 0xCAFE Entity Management Protocol (EMP) M M M = Mandatory 8.2 Routine 0x2202 – Check Memory Block The RoutineIdentifier allows the client to start a server routine which verifies the correctness of a programmed module. | CVS123-2.pdf | Hardware | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 30 / page 30 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 99 RFQX: RFQX-CVS123-2-0246 | 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. | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 30 / page 30 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 100 RFQX: RFQX-CVS123-2-0247 | The pre-calculated checksum shall be provided as part of the data submitted with the TransferData service request. | CVS123-2.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 30 / page 30 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 101 RFQX: RFQX-CVS123-2-0248 | It is server specific the generator polynomial and initial value to be used. | CVS123-2.pdf | IT / backend | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 30 / page 30 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 111 RFQX: RFQX-CVS123-2-0249 | 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 | CVS123-2.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 31 / page 31 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 102 RFQX: RFQX-CVS123-2-0250 | The server shall support the routine request according to Table 15. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 31 / page 31 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 103 RFQX: RFQX-CVS123-2-0251 | 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 The server shall support the routine positive response according to Table 16. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 31 / page 31 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 104 RFQX: RFQX-CVS123-2-0252 | Table 16: Routine 0x2202 Positive Response Format Byte Description Cvt Byte Value #1 RoutineControl Response SID M 0x71 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) checkMemory [byte#1] M 0x22 #4 routineIdentifier (LSB) checkMemory [byte#2] M 0x02 #5 routineStatus routineResult M 0x00-0xFF 8.2.3 Negative Response | CVS123-2.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 31 / page 31 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 114 RFQX: RFQX-CVS123-2-0253 | SUV2_REQ 4 prevents the scenario of erasing the copied bootloader while boot loader update and leaving the ECU without any bootloader. | CVS123-2.pdf | Hardware | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 32 / page 32 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 105 RFQX: RFQX-CVS123-2-0254 | The server shall support parameter routineStatus routineResult formatted according to Table 17. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 8.2.4 Routine 0x2202 Parameters 8.2.4.1 Parameter routineStatus routineResult / page 32 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_INFO 112 RFQX: RFQX-CVS123-2-0255 | This RoutineIdentifier value allows the client to start a routine which erases ECU internal non- volatile memory. | CVS123-2.pdf | Hardware | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 32 / page 32 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 106 RFQX: RFQX-CVS123-2-0256 | 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. | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 32 / page 32 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_INFO 113 RFQX: RFQX-CVS123-2-0257 | 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. | CVS123-2.pdf | Hardware | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 32 / page 32 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 107 RFQX: RFQX-CVS123-2-0258 | 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. | CVS123-2.pdf | Hardware | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS123-2 > Page 32 / page 32 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 4 RFQX: RFQX-CVS123-2-0259 | prevents the scenario of erasing the copied bootloader while boot loader update and leaving the ECU without any bootloader. | CVS123-2.pdf | Hardware | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS123-2 > Page 32 / page 32 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 108 RFQX: RFQX-CVS123-2-0260 | 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). | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 32 / page 32 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 109 RFQX: RFQX-CVS123-2-0261 | 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. | CVS123-2.pdf | Software | Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 32 / page 32 Pre-analysis Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 110 RFQX: RFQX-CVS123-2-0262 | The server shall support the routine request according to Table 18. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 8.3.1 Routine Request / page 33 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 111 RFQX: RFQX-CVS123-2-0263 | The server shall support the routine positive response according to Table 19. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 8.3.2 Routine Positive Response / page 33 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 112 RFQX: RFQX-CVS123-2-0264 | 8.3.4 Routine 0xFF00 Parameters 8.3.4.1 Parameter addressAndLengthFormatIdentifier | CVS123-2.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 34 / page 34 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 113 RFQX: RFQX-CVS123-2-0265 | The server shall support parameter addressAndLengthFormatIdentifier formatted according to Table 20. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 34 / page 34 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 62 RFQX: RFQX-CVS123-2-0266 | 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 & | CVS123-2.pdf | Software | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 34 / page 34 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 63 RFQX: RFQX-CVS123-2-0267 | . | CVS123-2.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 34 / page 34 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 114 RFQX: RFQX-CVS123-2-0268 | When the addressAndLengthFormatIdentifier is set to 0x01 the defined module to index mapping shall apply for the memoryStartAddress according to Table 21. | CVS123-2.pdf | System | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 34 / page 34 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 115 RFQX: RFQX-CVS123-2-0269 | The server shall support parameter routineStatus routineResult formatted according to Table 22. | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS123-2 > Page 34 / page 34 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_INFO 115 RFQX: RFQX-CVS123-2-0270 | This RoutineIdentifier value allows the client to start a consistency check of the server. | CVS123-2.pdf | IT / backend | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 8.4 Routine 0xFF01 – CheckProgrammingDependencies / page 35 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 143 RFQX: RFQX-CVS123-2-0271 | This RoutineIdentifier shall be able to execute independent from programming sequence | CVS123-2.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 35 / page 35 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_INFO 124 RFQX: RFQX-CVS123-2-0272 | The client may opt to execute this routineIdentifier as a standalone procedure to check to perform a software consistency check. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 35 / page 35 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 116 RFQX: RFQX-CVS123-2-0273 | The server shall check whether the individual modules are complete and compatible with one another. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 35 / page 35 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS123-2-0274 RFQX: RFQX-CVS123-2-0274 | 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). | CVS123-2.pdf | Software | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS123-2 > Page 35 / page 35 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 117 RFQX: RFQX-CVS123-2-0275 | The method used to check compatibility/consistency shall be determined by the supplier in consultation with the vehicle manufacturer. | CVS123-2.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 35 / page 35 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 118 RFQX: RFQX-CVS123-2-0276 | The consistency check shall be carried out solely by the server. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 35 / page 35 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 119 RFQX: RFQX-CVS123-2-0277 | The server shall verify the integrity of the software as a part of the consistency check. | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 35 / page 35 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 120 RFQX: RFQX-CVS123-2-0278 | The integrity information shall be supplied to the server before the software is updated. | CVS123-2.pdf | Software | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS123-2 > Page 35 / page 35 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 121 RFQX: RFQX-CVS123-2-0279 | The integrity check shall be carried out solely by the server. | CVS123-2.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 35 / page 35 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_INFO 140 RFQX: RFQX-CVS123-2-0280 | Details over the integrity check can be found on chapter 9.2. | CVS123-2.pdf | Interface | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 35 / page 35 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 122 RFQX: RFQX-CVS123-2-0281 | The server shall support the routine request according to Table 23. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 8.4.1 Request / page 35 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 123 RFQX: RFQX-CVS123-2-0282 | The server shall support the routine positive response according to Table 24. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 8.4.2 Positive Response / page 36 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 124 RFQX: RFQX-CVS123-2-0283 | 8.4.4 Routine 0xFF01 Parameters 8.4.4.1 Parameter routineStatus routineResult | CVS123-2.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 36 / page 36 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 125 RFQX: RFQX-CVS123-2-0284 | The server shall support parameter routineStatus routineResult formatted according to Table 25. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 36 / page 36 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 126 RFQX: RFQX-CVS123-2-0285 | 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 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. | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 36 / page 36 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RFQX-CVS123-2-0286 RFQX: RFQX-CVS123-2-0286 | 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 | CVS123-2.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS123-2 > Page 36 / page 36 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 146 RFQX: RFQX-CVS123-2-0287 | • Routine 0xFF00 Erase Memory | CVS123-2.pdf | Hardware | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 37 / page 37 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 151 RFQX: RFQX-CVS123-2-0288 | • Service 0x34 RequestDownload | CVS123-2.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 37 / page 37 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 169 RFQX: RFQX-CVS123-2-0289 | • Service 0x36 TransferData | CVS123-2.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 37 / page 37 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 170 RFQX: RFQX-CVS123-2-0290 | • Service 0x37 RequestTransferExit 8.4.4.2 Parameter routineResultProofLength | CVS123-2.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 37 / page 37 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 128 RFQX: RFQX-CVS123-2-0291 | This parameter consist of the length of the routineResultProof parameter. | CVS123-2.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 37 / page 37 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 171 RFQX: RFQX-CVS123-2-0292 | The server shall hash the receipt number with the routineStatus routineResult parameter, in this respective order. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 8.4.4.3 Parameter routineResultProof / page 37 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_INFO 138 RFQX: RFQX-CVS123-2-0293 | The receipt number is received as part of the EMP message whenever a SDSC is set, please refer to CVS34. | CVS123-2.pdf | Interface | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 37 / page 37 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 172 RFQX: RFQX-CVS123-2-0294 | The hash algorithm shall be SHA512. | CVS123-2.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS123-2 > Page 37 / page 37 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 173 RFQX: RFQX-CVS123-2-0295 | The server shall sign the hashed output using the receipt-keys. | CVS123-2.pdf | IT / backend | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS123-2 > Page 37 / page 37 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_INFO 139 RFQX: RFQX-CVS123-2-0296 | For information on receipt-keys, please refer to CVS34. | CVS123-2.pdf | System | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 37 / page 37 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 174 RFQX: RFQX-CVS123-2-0297 | The server shall use ED25519 as signature algorithm. | CVS123-2.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 37 / page 37 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 175 RFQX: RFQX-CVS123-2-0298 | The server shall return in the parameter routineResultProof the signed hash. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 37 / page 37 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 183 RFQX: RFQX-CVS123-2-0299 | The client shall send the Servers routineStatus routineResult response to the backend. | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page Figure 5: diagram for signing of software update results 8.4.4.4 Client behaviour after server software verification / page 38 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 128 RFQX: RFQX-CVS123-2-0300 | SDSC is transmitted via EMP, see chapter 9. | CVS123-2.pdf | Interface | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 8.5 Routine 0xCAFE – Entity Management Protocol (EMP) / page 38 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 141 RFQX: RFQX-CVS123-2-0301 | The SDSC content, including the reference hash used for software verification, is signed as part of the set request when transmitted over EMP. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 38 / page 38 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 176 RFQX: RFQX-CVS123-2-0302 | 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. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 38 / page 38 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 177 RFQX: RFQX-CVS123-2-0303 | Once a SDSC has being accepted by the server, the server shall accept the following diagnostic services and routines: • Routine 0xFF00 Erase Memory | CVS123-2.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS123-2 > Page 38 / page 38 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 178 RFQX: RFQX-CVS123-2-0304 | • Service 0x34 RequestDownload | CVS123-2.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 38 / page 38 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 179 RFQX: RFQX-CVS123-2-0305 | • Service 0x36 TransferData | CVS123-2.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 38 / page 38 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 180 RFQX: RFQX-CVS123-2-0306 | • Service 0x37 RequestTransferExit | CVS123-2.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 38 / page 38 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 131 RFQX: RFQX-CVS123-2-0307 | Negative Response | CVS123-2.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 8.5.3 Negative Response / page 39 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 129 RFQX: RFQX-CVS123-2-0308 | The server shall support the routine request according to Table 26. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 8.5.1 Request / page 39 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 130 RFQX: RFQX-CVS123-2-0309 | 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 The server shall support the routine positive response according to Table 27. | CVS123-2.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 39 / page 39 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 132 RFQX: RFQX-CVS123-2-0310 | The server shall support the routine negative response according to CVS33. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 39 / page 39 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 133 RFQX: RFQX-CVS123-2-0311 | The server shall support the parameter EMP message according to CVS33. | CVS123-2.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 8.5.4 Routine 0xCAFE Parameters 8.5.4.1 Parameter EMP Message / page 39 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_INFO 117 RFQX: RFQX-CVS123-2-0312 | 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). | CVS123-2.pdf | Cybersecurity | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 9 Software Verification and Encryption Requirements / page 40 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| SUV2_REQ 134 RFQX: RFQX-CVS123-2-0313 | The server shall implement SDSC structure as defined in CVS154. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 9.1 General Requirements on SDSC 9.1.1 SDSC Structure / page 40 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_INFO 119 RFQX: RFQX-CVS123-2-0314 | SDSC supports verification entries, encryption entries and items as defined in DSC. | CVS123-2.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 40 / page 40 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 120 RFQX: RFQX-CVS123-2-0315 | For the context of SDSC, range is defined as: • Start = memory address offset to be verified/decrypted. | CVS123-2.pdf | Hardware | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 40 / page 40 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 184 RFQX: RFQX-CVS123-2-0316 | The range start field shall be the memory address offset from the dataLocator field. | CVS123-2.pdf | Hardware | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS123-2 > Page 40 / page 40 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 185 RFQX: RFQX-CVS123-2-0317 | The range length field shall be the number of bytes to be verified. | CVS123-2.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS123-2 > Page 40 / page 40 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_INFO 138 RFQX: RFQX-CVS123-2-0318 | For the context of SDSC, dataLocator is defined as an identification the server uses to locate the software module. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 40 / page 40 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 161 RFQX: RFQX-CVS123-2-0319 | The supplier shall propose for each software module an identification to be used in dataLocator field in SDSC. | CVS123-2.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 40 / page 40 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 168 RFQX: RFQX-CVS123-2-0320 | The vehicle manufacturer shall review and accept the proposals for every dataLocator. | CVS123-2.pdf | Process / compliance | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 40 / page 40 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_INFO 135 RFQX: RFQX-CVS123-2-0321 | The dataLocator field is used to provide to the server the means to identify which module the verification or encryption entries refer to. | CVS123-2.pdf | IT / backend | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 40 / page 40 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS123-2-0322 RFQX: RFQX-CVS123-2-0322 | 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. | CVS123-2.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS123-2 > Page 40 / page 40 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 135 RFQX: RFQX-CVS123-2-0323 | Before accepting the SDSC as valid, the server shall perform the sanity check of the received SDSC as defined in CVS154. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 9.1.2 SDSC Sanity Check / page 40 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_INFO 121 RFQX: RFQX-CVS123-2-0324 | In DSC sanity check, there is a specific area of application sanity check which depends on the context of the general DSC. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 41 / page 41 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 138 RFQX: RFQX-CVS123-2-0325 | If the sanity check returns fail/invalid, the server shall reject SDSC as described in CVS34. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 41 / page 41 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 152 RFQX: RFQX-CVS123-2-0326 | The server shall validate each VerificationEntry found in the SDSC. | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 9.2 Software Verification / page 41 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_INFO 125 RFQX: RFQX-CVS123-2-0327 | The referenceHash defines the reference hash value to be used in the hash comparison. | CVS123-2.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 41 / page 41 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 153 RFQX: RFQX-CVS123-2-0328 | Software hashes in the SDSC shall be verified by the server considering the ranges which are stated in the SDSC. | CVS123-2.pdf | Software | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 41 / page 41 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 154 RFQX: RFQX-CVS123-2-0329 | The Ranges dictates the data range that the server shall begin, and end read from NVM for hashing. | CVS123-2.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 41 / page 41 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_INFO 126 RFQX: RFQX-CVS123-2-0330 | 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. | CVS123-2.pdf | Hardware | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 41 / page 41 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 155 RFQX: RFQX-CVS123-2-0331 | When hashing software, the whole memory range, including erased-only bytes of a memory module, shall be possible to include in the hash calculation. | CVS123-2.pdf | Software | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 41 / page 41 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_INFO 127 RFQX: RFQX-CVS123-2-0332 | Erased-only bytes are parts of the memory module that are not programmed with data. | CVS123-2.pdf | Hardware | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 41 / page 41 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 156 RFQX: RFQX-CVS123-2-0333 | 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. | CVS123-2.pdf | Software | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page Figure 6: Erased-only bytes of a memory module / page 41 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 157 RFQX: RFQX-CVS123-2-0334 | The server shall be able to verify that erased-only blocks covered in range of memory are erased. | CVS123-2.pdf | Hardware | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 42 / page 42 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 158 RFQX: RFQX-CVS123-2-0335 | When the server has verified all verificationEntries, a result OK/NOT_OK shall be returned. | CVS123-2.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 42 / page 42 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_REQ 159 RFQX: RFQX-CVS123-2-0336 | If NOT_OK is returned, the server shall not accept the new software for execution. | CVS123-2.pdf | Software | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 42 / page 42 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 160 RFQX: RFQX-CVS123-2-0337 | If OK is returned, the server shall accept that installed software is valid in terms of integrity. | CVS123-2.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 42 / page 42 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SUV2_INFO 131 RFQX: RFQX-CVS123-2-0338 | The server may execute other checks to verify the software before concluding if the installed software shall be accepted. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS123-2 > Page 42 / page 42 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 147 RFQX: RFQX-CVS123-2-0339 | 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. | CVS123-2.pdf | Software | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 9.3 Software decryption / page 42 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 148 RFQX: RFQX-CVS123-2-0340 | An initialized data (i.e., cipher scheme) shall be kept active until no more received data matches the current EncryptionEntry. | CVS123-2.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS123-2 > Page 42 / page 42 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 149 RFQX: RFQX-CVS123-2-0341 | The cipher shall be reinitialized for each new Encryption entry. | CVS123-2.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS123-2 > Page 42 / page 42 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 150 RFQX: RFQX-CVS123-2-0342 | According to best practise received data shall be decrypted “on the fly” before storing to NVM. | CVS123-2.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS123-2 > Page 42 / page 42 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS123-2-0343 RFQX: RFQX-CVS123-2-0343 | Other methods shall be agreed upon with OEM. | CVS123-2.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS123-2 > Page 42 / page 42 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_INFO 134 RFQX: RFQX-CVS123-2-0344 | The received data to decrypt may only be parts of a software module and it will be based on the range defined. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 42 / page 42 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 133 RFQX: RFQX-CVS123-2-0345 | EncryptionEntries are not present if software is not encrypted. | CVS123-2.pdf | Software | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS123-2 > Page 42 / page 42 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_INFO 132 RFQX: RFQX-CVS123-2-0346 | The Non-volatile server memory programming complete flow can be found in Annex B. | CVS123-2.pdf | Hardware | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page 10 Non-volatile server memory programming complete flow / page 42 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 00868000 RFQX: RFQX-CVS123-2-0347 | #008AFFFF # | CVS123-2.pdf | System | Source classifies this as Unknown (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 47 / page 47 Pre-analysis Source classifies this as Unknown (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 00930000 RFQX: RFQX-CVS123-2-0348 | #00BFFFFF #008B0000 #0092FFFF Module hashData #00AFAAAA #00AFAAAB Figure 8 – Memory layout | CVS123-2.pdf | Hardware | Source classifies this as Unknown (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS123-2 > Page 47 / page 47 Pre-analysis Source classifies this as Unknown (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS123-2-0349 RFQX: RFQX-CVS123-2-0349 | 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). | CVS123-2.pdf | Hardware | Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 48 / page 48 Pre-analysis Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| 00930000 RFQX: RFQX-CVS123-2-0350 | #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. | CVS123-2.pdf | Hardware | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS123-2 > Page 50 / page 50 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RFQX-CVS123-2-0351 RFQX: RFQX-CVS123-2-0351 | 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. | CVS123-2.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS123-2 > Page 50 / page 50 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RFQX-CVS124-0001 RFQX: RFQX-CVS124-0001 | The User shall apply the latest version of this CVS124. | CVS124.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS124 > Page 1 / page 1 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS124-0002 RFQX: RFQX-CVS124-0002 | Foreword This CVS124 contains requirement specification for TRATON GROUP and may be used by all within TRATON Group, if applicable. | CVS124.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 2 / page 2 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No supplier action - document reference / boilerplate. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS124-0003 RFQX: RFQX-CVS124-0003 | 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”. | CVS124.pdf | Process / compliance | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS124 > Page 2 / page 2 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS124-0004 RFQX: RFQX-CVS124-0004 | • 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. | CVS124.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS124 > Page 2 / page 2 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| 4.1 RFQX: RFQX-CVS124-0005 | 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. Shall not This phrase, or the phrase "Must not", means that the definition is an absolute prohibition of the specification. 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. 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. May This word, or the adjective “Optional”, means that an item is truly optional. 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. 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. 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). | CVS124.pdf | IT / backend | Low extraction confidence or flagged for human review. Linked source table/diagram context was considered for interpretation. | Needs internal review. Confirm the extracted wording and the intended scope before committing a supplier position. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Re-read the Source document, confirm intent, then re-issue an Accept/Partial position. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 6 / page 6 Pre-analysis Low extraction confidence or flagged for human review. Linked source table/diagram context was considered for interpretation. Assumptions Internal review confirms wording and scope. Engineering notes Complete internal review of wording and baseline scope. Risk / impact Limited; standard implementation and verification risk. |
| 4.2 RFQX: RFQX-CVS124-0006 | Table 2 – Abbreviated terms Abbreviation Description DID Data Identifier EnvCond Environment Condition FMI Failure Mode Indication Def Default diagnostic session DSIV Diagnostic Security Implementation Variant Project specific. Dependent of the security variant implemented in the diagnostic server. DTC Diagnostic Trouble Code ECU Electronic Control Unit Ext Extended diagnostic session UDS Unified Diagnostic Services CAN Controller Area Network | CVS124.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 6 / page 6 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No supplier action - document reference / boilerplate. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS124-0007 RFQX: RFQX-CVS124-0007 | Shall not This phrase, or the phrase "Must not", means that the definition is an absolute prohibition of the specification. | CVS124.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 6 / page 6 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS124-0008 RFQX: RFQX-CVS124-0008 | 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. | CVS124.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 6 / page 6 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS124-0009 RFQX: RFQX-CVS124-0009 | 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. | CVS124.pdf | System | Non-mandatory wording; baseline inclusion not yet confirmed. | Needs internal review. Confirm whether this should-level requirement is in the committed baseline. | Decide baseline inclusion internally, then issue an Accept/Partial position. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 6 / page 6 Pre-analysis Non-mandatory wording; baseline inclusion not yet confirmed. Assumptions Internal baseline decision recorded. Engineering notes Complete internal review of wording and baseline scope. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS124-0010 RFQX: RFQX-CVS124-0010 | May This word, or the adjective “Optional”, means that an item is truly optional. | CVS124.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 6 / page 6 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS124-0011 RFQX: RFQX-CVS124-0011 | 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. | CVS124.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 6 / page 6 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS124-0012 RFQX: RFQX-CVS124-0012 | 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. | CVS124.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 6 / page 6 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS124-0013 RFQX: RFQX-CVS124-0013 | 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). | CVS124.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 6 / page 6 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| 4.3 RFQX: RFQX-CVS124-0014 | Table 3 – Conventions Implementation Description M Mandatory Mandatory data marked as ‘M’ always shall be returned. If valid data is not needed for the use-case and system at hand, default values should be used. E Mandatory for ECUs which shall be compliant with OBD legislation Worldwide like ISO27145,J1979 etc C Conditional U User optional. Shall be agreed between the supplier and the vehicle manufacturer. - (dash) Not supported Table 4 – Definitions of terms Changing Description DIAG Diagnostics - The Data Identifier content can be changed by means of the UDS service 0x2E FLASH BOOT Boot loader module stored in flash memory FLASH APPL Application module stored in flash memory FLASH DATA Dataset download - The Data Identifier content is changed by a dataset download process as per document Harmonized programming (see /11/) SUPPLIER Supplier process - The Data Identifier content is changed at the supplier's facilities by the manufacturing process. INTERNAL ECU software - The Data Identifier content is determined by the server at runtime. | CVS124.pdf | Software | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 7 / page 7 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RFQX-CVS124-0015 RFQX: RFQX-CVS124-0015 | If valid data is not needed for the use-case and system at hand, default values should be used. | CVS124.pdf | System | Non-mandatory wording; baseline inclusion not yet confirmed. | Needs internal review. Confirm whether this should-level requirement is in the committed baseline. | Decide baseline inclusion internally, then issue an Accept/Partial position. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 7 / page 7 Pre-analysis Non-mandatory wording; baseline inclusion not yet confirmed. Assumptions Internal baseline decision recorded. Engineering notes Complete internal review of wording and baseline scope. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS124-0016 RFQX: RFQX-CVS124-0016 | E Mandatory for ECUs which shall be compliant with OBD legislation Worldwide like ISO27145,J1979 etc C Conditional U User optional. | CVS124.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 7 / page 7 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS124-0017 RFQX: RFQX-CVS124-0017 | Shall be agreed between the supplier and the vehicle manufacturer. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 7 / page 7 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0001 RFQX: RFQX-CVS124-0018 | The implementation of the client and the server shall be compliant with ISO 14229-1 with the | CVS124.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 8 / page 8 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_UDS_0002 RFQX: RFQX-CVS124-0019 | All deviations and extensions shall be agreed with the applicable vehicle manufacturer and shall be documented. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 8 / page 8 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0003 RFQX: RFQX-CVS124-0020 | Table 5 -Data identifiers used at ECU identification DID Description/ Name Application Boot loader Changing Def Non- Def Def Ext Prg Ext 0xF180 bootSoftwareIdentificationDataIdentifier ● ● ● ● ● SUPPLIER 0xF181 applicationSoftwareIdentificationDataIdentifier ● ● ● ● ● SUPPLIER 0xF182 applicationDataIdentificationDataIdentifier ● ● ● ● ● SUPPLIER 0xF186 ActiveDiagnosticSessionDataIdentifier ● ● ● ● ● INTERNAL 0xF187 vehicleManufacturerSparePartNumberDataIdentifier ● ○ ● ○ ○ SUPPLIER 0xF188 vehicleManufacturerECUSoftwareNumberDataIdent ifier ● ● ● ● ● SUPPLIER 0xF189 vehicleManufacturerECUSoftwareVersionNumberD ataIdentifier ● ● ● ● ● SUPPLIER 0xF18A systemSupplierIdentifierDataIdentifier ● ● - - - SUPPLIER 0xF18B ECUManufacturingDateDataIdentifier ● ● ● ● ● SUPPLIER 0xF18C ECUSerialNumberDataIdentifier ● ● ● ● ● SUPPLIER 0xF190 VINDataIdentifier ● ○ ● ● ● DIAG 0xF191 vehicleManufacturerECUHardwareNumberDataIde ntifier ● ● ● ● ● SUPPLIER 0xF192 systemSupplierECUHardwareNumberDataIdentifier ● ● - - - SUPPLIER 0xF193 systemSupplierECUHardwareVersionNumberDataI dentifier ● ● - - - SUPPLIER 0xF194 systemSupplierECUSoftwareNumberDataIdentifier ● ● - - - SUPPLIER | CVS124.pdf | Software | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 5.2 ECU Identification Requirements 5.2.1 Used data identifier in order to identify an ECU / page 8 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| INFO_UDS_0001 RFQX: RFQX-CVS124-0021 | SUPPLIER in the Changing column means that the DID can be changed only at the supplier premises for non-programmable ECUs. Data identifier details. | CVS124.pdf | Interface | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 9 / page 9 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| INFO_UDS_0002 RFQX: RFQX-CVS124-0022 | The format in the DID description in the following tables is given in ODX base data types. | CVS124.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 9 / page 9 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0004 RFQX: RFQX-CVS124-0023 | Table 6 – Description of DID 0xF180 bootSoftwareIdentificationDataIdentifier 0xF180 Name : bootSoftwareIdentificationDataIdentifier Byte | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 10 / page 10 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0005 RFQX: RFQX-CVS124-0024 | This DID shall be stored under flash memory module in flash memory. | CVS124.pdf | Hardware | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 0x20 / page 10 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0006 RFQX: RFQX-CVS124-0025 | 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 | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.2.1.2 DID 0xF181 applicationSoftwareIdentificationDataIdentifier / page 10 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0231 RFQX: RFQX-CVS124-0026 | 5.2.1.3 DID 0xF182 applicationDataIdentificationDataIdentifier | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 11 / page 11 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0007 RFQX: RFQX-CVS124-0027 | 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 . | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 11 / page 11 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0232 RFQX: RFQX-CVS124-0028 | This DID shall be stored under dataset module stored in flash memory. | CVS124.pdf | Hardware | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 0x7E 0x20 / page 11 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0008 RFQX: RFQX-CVS124-0029 | 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 | CVS124.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 5.2.1.4 DID 0xF186 ActiveDiagnosticSessionDataIdentifier / page 11 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0009 RFQX: RFQX-CVS124-0030 | 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 | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 12 / page 12 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0233 RFQX: RFQX-CVS124-0031 | This DID shall be stored under dataset module stored in flash memory. | CVS124.pdf | Hardware | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 12 / page 12 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0010 RFQX: RFQX-CVS124-0032 | Table 11 – Description of DID 0xF188 vehicleManufacturerECUSoftwareNumberDataIdentifier 0xF188 Name: vehicleManufacturerECUSoftwareNumberDataIdentifier Byte Data #1 : #13 Vehicle manufacturer ECU (server) software number : M : M : 0x20 | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 12 / page 12 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0234 RFQX: RFQX-CVS124-0033 | 5.2.1.7 DID 0xF189 vehicleManufacturerECUSoftwareVersionNumberDataIdentifier | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 12 / page 12 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0011 RFQX: RFQX-CVS124-0034 | Table 12 – Description of DID 0xF189 vehicleManufacturerECUSoftwareVersionNumberDataIdentifier 0xF189 Name: vehicleManufacturerECUSoftwareVersionNumberDataIdentifier Byte Data | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 12 / page 12 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0235 RFQX: RFQX-CVS124-0035 | 5.2.1.8 DID 0xF18A systemSupplierIdentifierDataIdentifier | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 13 / page 13 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0012 RFQX: RFQX-CVS124-0036 | 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 | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 13 / page 13 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0013 RFQX: RFQX-CVS124-0037 | Table 14 – Description of DID 0xF18B ECUManufacturingDateDataIdentifier 0xF18B Name: ECUManufacturingDateDataIdentifier Byte Data #1 . | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 13 / page 13 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0014 RFQX: RFQX-CVS124-0038 | Table 15 – Description of DID 0xF18C ECUSerialNumberDataIdentifier 0xF18C Name: ECUSerialNumberDataIdentifier Byte Data | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 14 / page 14 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS124-0039 RFQX: RFQX-CVS124-0039 | Minimum length shall be 8 bytes and the assigned value shall be unique for every unit provided by one supplier per project. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS124 > Page 14 / page 14 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0015 RFQX: RFQX-CVS124-0040 | Table 16 – Description of DID 0xF190 VINDataIdentifier 0xF190 Name: VINDataIdentifier Byte Data #1 : #17 VIN number : Byte #17 17-Bytes- M : M : 0x30 . | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.2.1.11 DID 0xF190 VINDataIdentifier / page 14 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| INFO_UDS_0003 RFQX: RFQX-CVS124-0041 | This identifier is used for follow up and quality check at production and service and for legal reasons if applicable. | CVS124.pdf | Software | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 0x30 / page 14 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0016 RFQX: RFQX-CVS124-0042 | Table 17 – Description of DID 0xF191 vehicleManufacturerECUHardwareNumberDataIdentifier 0xF191 Name: vehicleManufacturerECUHardwareNumberDataIdentifier Byte Data | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.2.1.12 DID 0xF191 vehicleManufacturerECUHardwareNumberDataIdentifier / page 14 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0236 RFQX: RFQX-CVS124-0043 | This DID shall be stored under flash memory module in flash memory. | CVS124.pdf | Hardware | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 0x20 / page 15 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0017 RFQX: RFQX-CVS124-0044 | 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 | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 15 / page 15 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0018 RFQX: RFQX-CVS124-0045 | 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 | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 15 / page 15 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0019 RFQX: RFQX-CVS124-0046 | 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 | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 15 / page 15 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0237 RFQX: RFQX-CVS124-0047 | DID 0xF197 systemNameOrEngineTypeDataIdentifier | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.2.1.18 DID 0xF197 systemNameOrEngineTypeDataIdentifier / page 16 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0020 RFQX: RFQX-CVS124-0048 | 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 | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 16 / page 16 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0021 RFQX: RFQX-CVS124-0049 | 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 | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 16 / page 16 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0022 RFQX: RFQX-CVS124-0050 | 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 . | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 16 / page 16 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| INFO_UDS_0039 RFQX: RFQX-CVS124-0051 | The format should follow the pattern: Appl: <Diag.family> <Diag.generation> Boot: <Diag.family> <Diag.generation>_BOOT | CVS124.pdf | System | Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 16 / page 16 Pre-analysis Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0339 RFQX: RFQX-CVS124-0052 | DID 0xF198 SoftwareItemSemanticDataIdentifiers | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.2.1.19 DID 0xF198 SoftwareItemSemanticDataIdentifiers / page 17 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0340 RFQX: RFQX-CVS124-0053 | 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 | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.2.1.20 DID 0xF199 SoftwareAssemblySemanticDataIdentifiers / page 17 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0341 RFQX: RFQX-CVS124-0054 | 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. | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.2.1.21 DID 0xF19A HardwareSemanticDataIdentifiers / page 18 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0023 RFQX: RFQX-CVS124-0055 | Table 27 – Description of DID 0xF19D ECUInstallationDateDataIdentifier 0xF19D Name: ECUInstallationDateDataIdentifier Byte Data | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 19 / page 19 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0025 RFQX: RFQX-CVS124-0056 | 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 | CVS124.pdf | Hardware | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 19 / page 19 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0026 RFQX: RFQX-CVS124-0057 | 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 | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 19 / page 19 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0027 RFQX: RFQX-CVS124-0058 | This DID shall contain a snapshot of the mandatory lifetime ECU-runtime operational data | CVS124.pdf | Hardware | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 20 / page 20 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0028 RFQX: RFQX-CVS124-0059 | 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 | CVS124.pdf | Software | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 20 / page 20 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0029 RFQX: RFQX-CVS124-0060 | 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. | CVS124.pdf | Software | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 20 / page 20 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0030 RFQX: RFQX-CVS124-0061 | 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. | CVS124.pdf | Software | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 20 / page 20 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| INFO_UDS_0004 RFQX: RFQX-CVS124-0062 | The current date as received on CAN or other ECU-external source at first reception of a valid signal after a software update. | CVS124.pdf | Software | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 5.2.1.27 DID 0xF1AB Date at software update stamp / page 20 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0032 RFQX: RFQX-CVS124-0063 | Table 32 – Description of DID 0xF1AB Date at software update stamp 0xF1AB Name: dateAtSoftwareUpdateStamp Byte Data | CVS124.pdf | Software | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 21 / page 21 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0033 RFQX: RFQX-CVS124-0064 | 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 | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 21 / page 21 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0034 RFQX: RFQX-CVS124-0065 | Table 34 – Description of DID 0xF1AF NodeUID 0xF1AF Name: NodeUID Byte Data #1 : #8 NodeUID 8-Bytes- A_BYTEFIELD M : M : 0x00 : 0x00 | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 21 / page 21 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| INFO_UDS_0005 RFQX: RFQX-CVS124-0066 | This identifier is used to link a ECU HW to its specialized security attributes. | CVS124.pdf | Cybersecurity | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 22 / page 22 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| INFO_UDS_0040 RFQX: RFQX-CVS124-0067 | The value to be stored is fetched from TRATON backend system in production. | CVS124.pdf | IT / backend | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 22 / page 22 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0036 RFQX: RFQX-CVS124-0068 | 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 | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 22 / page 22 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| INFO_UDS_0006 RFQX: RFQX-CVS124-0069 | Information on RBACC can be found in CVS151. | CVS124.pdf | Interface | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 22 / page 22 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0037 RFQX: RFQX-CVS124-0070 | 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 | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 22 / page 22 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| INFO_UDS_0007 RFQX: RFQX-CVS124-0071 | Information on RBACC can be found in CVS151. | CVS124.pdf | Interface | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 22 / page 22 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0038 RFQX: RFQX-CVS124-0072 | Table 37 – Description of DID 0xF1D1 RootCertificateIdentifier 0xF1D1 Name: RootCertificateIdentifier Byte Data | CVS124.pdf | System | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 5.2.1.32 DID 0xF1D1 RootCertificateIdentifier / page 22 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0039 RFQX: RFQX-CVS124-0073 | 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 | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 23 / page 23 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0238 RFQX: RFQX-CVS124-0074 | This DID shall be stored under flash memory module in flash memory. | CVS124.pdf | Hardware | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 23 / page 23 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0040 RFQX: RFQX-CVS124-0075 | A default diagnostic session shall be supported. | CVS124.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 5.3 Diagnostic sessions requirements / page 23 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| REQ_UDS_0041 RFQX: RFQX-CVS124-0076 | The default diagnostic session is referred to as “defaultSession”. | CVS124.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 23 / page 23 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0042 RFQX: RFQX-CVS124-0077 | A non-default diagnostic session referred to as “extendedDiagnosticSession” shall be supported. | CVS124.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 23 / page 23 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| REQ_UDS_0043 RFQX: RFQX-CVS124-0078 | Diagnostic sessions not defined in this document shall be agreed with the vehicle manufacturer. | CVS124.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 23 / page 23 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| REQ_UDS_0044 RFQX: RFQX-CVS124-0079 | Of a marked service, an execution shall be implemented for the specified session as perTable 39. | CVS124.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 23 / page 23 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0045 RFQX: RFQX-CVS124-0080 | Table 39 – Diagnostic service support Service according to ISO 14229-1 Addressin g mode Application Boot loader | CVS124.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 24 / page 24 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| INFO_UDS_0038 RFQX: RFQX-CVS124-0081 | In Table 39, bootloader sessions should only be applicable to Software updateable ECUs. | CVS124.pdf | Software | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 25 / page 25 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0046 RFQX: RFQX-CVS124-0082 | The mapping of RoutineControl service routines to sessions shall be discussed and agreed with the vehicle manufacturer. | CVS124.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 25 / page 25 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0047 RFQX: RFQX-CVS124-0083 | The server shall implement support for RBAC (Role Based Access Control) based on CVS151. | CVS124.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 25 / page 25 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_UDS_0048 RFQX: RFQX-CVS124-0084 | CVS31 and CVS32 requirements preconditions per service shall be defined by the RBAC Configuration file in the ECU. | CVS124.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 25 / page 25 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0049 RFQX: RFQX-CVS124-0085 | Diagnostics safe state is the following conditions that needs be satisfied to ensure vehicle is not in operation while performing certain diagnostics services. | CVS124.pdf | System | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 25 / page 25 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| INFO_UDS_0008 RFQX: RFQX-CVS124-0086 | 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 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 | CVS124.pdf | System | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 25 / page 25 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0050 RFQX: RFQX-CVS124-0087 | Diagnostics safe state shall be checked before executing the diagnostics services as per Table 40. | CVS124.pdf | System | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 25 / page 25 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0051 RFQX: RFQX-CVS124-0088 | The server implementation shall comply with the following state diagram and the following state | CVS124.pdf | IT / backend | Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 26 / page 26 Pre-analysis Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_UDS_0338 RFQX: RFQX-CVS124-0089 | The session transitions stated below shall be possible to request both physically or functionally | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 27 / page 27 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0305_1 RFQX: RFQX-CVS124-0090 | . Default transition for the start of the software in the server after power-up/wake-up. | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 27 / page 27 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| INFO_UDS_0019 RFQX: RFQX-CVS124-0091 | Description of the individual transitions as per Figure 2 -State Diagram is explained from | CVS124.pdf | System | Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 27 / page 27 Pre-analysis Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0305 RFQX: RFQX-CVS124-0092 | to | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 27 / page 27 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0337 RFQX: RFQX-CVS124-0093 | . | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 27 / page 27 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0306_2 RFQX: RFQX-CVS124-0094 | . The initialization routine is started. | CVS124.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 28 / page 28 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0307_3 RFQX: RFQX-CVS124-0095 | . If a valid application software is available in the server (applValid P1 == true) and there is no programming request (progRequest P2 == false), the server changes to the DefaultSession in the application software. | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 28 / page 28 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0308_4 RFQX: RFQX-CVS124-0096 | . If a programming request is active (progRequest P2 == true), the server activates the programming session in the bootloader module. | CVS124.pdf | IT / backend | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 28 / page 28 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0309_5 RFQX: RFQX-CVS124-0097 | . If there is no programming request (progRequest P2 == false) and no valid application software is available (applValid P1 == false), the server changes to the DefaultSession in the boot loader. | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 28 / page 28 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0310_6 RFQX: RFQX-CVS124-0098 | . If the client posts a physical service request to change session from DefaultSession to ProgrammingSession in the application software, the server sends a negative response with NRC 0x7E (sub-functionNotSupportedInActiveSession). Applies to non-reprogrammable servers: If the client requests a change to the ProgrammingSession in the DefaultSession in the application software, the server | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 28 / page 28 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0311_7 RFQX: RFQX-CVS124-0099 | . If the client requests a change to the ExtendedSession in the DefaultSession in the application software, the session is changed. | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 28 / page 28 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0312_8 RFQX: RFQX-CVS124-0100 | . If the client does not send any requests during a time period defined by S3Server in the ExtendedSession in the application software, the server falls back into the DefaultSession in the application software. | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 28 / page 28 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0313_9 RFQX: RFQX-CVS124-0101 | . If the client requests a change to the DefaultSession in the ExtendedSession in the application software, the session is changed. | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 28 / page 28 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0314_10 RFQX: RFQX-CVS124-0102 | . If the client requests a change to the ProgrammingSession in the ExtendedSession in the application software, the server sets the progRequest flag to "true", so that after restarting it can be seen, that changing to the ProgrammingSession has been requested. If the SPRMIB was not set a positive response is sent from the application before the transition to Bootloader. The request is only sent physically. | CVS124.pdf | Software | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 28 / page 28 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0315_11 RFQX: RFQX-CVS124-0103 | . If the client requests a change to the ExtendedSession in ExtendedSession in the application software, the server accepts the request. | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 28 / page 28 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0306 RFQX: RFQX-CVS124-0104 | 2. | CVS124.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 28 / page 28 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0316_12 RFQX: RFQX-CVS124-0105 | . If the client requests an ECUReset (0x11) with the sub-function HardReset (0x01) in the boot loader ExtendedSession or ProgrammingSession, the reset is performed. | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0317_13 RFQX: RFQX-CVS124-0106 | . If the client requests a change to the DefaultSession in the boot loader ExtendedSession or ProgrammingSession, the reset is performed. | CVS124.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0318_14 RFQX: RFQX-CVS124-0107 | . If the client does not send any requests during a time period defined by S3Server in a Non-DefaultSession in the boot loader, the server performs a reset. | CVS124.pdf | IT / backend | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0319_15 RFQX: RFQX-CVS124-0108 | . If the client requests a change to the DefaultSession in the DefaultSession in the boot loader, the server accepts the request. | CVS124.pdf | IT / backend | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0320_16 RFQX: RFQX-CVS124-0109 | . If the client requests an ECUReset (0x11) with the sub-function HardReset (0x01) in the DefaultSession in the boot loader, the reset is performed. | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0321_17 RFQX: RFQX-CVS124-0110 | . If the client requests the ExtendedSession in the DefaultSession in the boot loader, the session is changed. | CVS124.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0322_18 RFQX: RFQX-CVS124-0111 | . If the client posts a physical service request to change session from DefaultSession to ProgrammingSession in the boot loader, the server sends a negative response with NRC 0x7E (sub-functionNotSupportedInActiveSession). | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0323_19 RFQX: RFQX-CVS124-0112 | . If the client requests the ExtendedSession in the ExtendedSession in the boot loader, the server accepts the request. | CVS124.pdf | IT / backend | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0324_20 RFQX: RFQX-CVS124-0113 | . If the client requests the ProgrammingSession in the ExtendedSession in the boot loader, the session is changed regardless of whether the programming preconditions are fulfilled or not. The request is only sent physically. | CVS124.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0325_21 RFQX: RFQX-CVS124-0114 | . If the client requests a change to the ProgrammingSession in ProgrammingSession in the boot loader, the server accepts the request. The request is only sent physically. | CVS124.pdf | IT / backend | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0326_22 RFQX: RFQX-CVS124-0115 | . If the client posts a physical service request to change session from ProgrammingSession to ExtendedSession in the boot loader, the server sends a negative response with NRC 0x7E (sub-functionNotSupportedInActiveSession). | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0327_23 RFQX: RFQX-CVS124-0116 | . If the client requests the DefaultSession in the DefaultSession in the application, the server accepts the request. | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0316 RFQX: RFQX-CVS124-0117 | 12. | CVS124.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0328_24 RFQX: RFQX-CVS124-0118 | . Applies to terminal 15 powered servers: If the client requests an ECUReset with the sub-function KeyOffOnReset (0x02) in the ExtendedSession in the application software, a restart is performed. | CVS124.pdf | Software | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 30 / page 30 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0329_25 RFQX: RFQX-CVS124-0119 | . Applies to terminal 15 powered servers: If the client requests an ECUReset with the sub-function KeyOffOnReset (0x02) in the DefaultSession in the application software, a restart is performed. | CVS124.pdf | Software | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 30 / page 30 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0330_26 RFQX: RFQX-CVS124-0120 | . If a server exchanges diagnostic messages with the client within the ExtendedSession and state terminal 15 ON, the following step is performed if there is a change to terminal 15 OFF and response in progress was finished: Return to DefaultSession after an already started response message has been completely sent to the client. | CVS124.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 30 / page 30 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0331_27 RFQX: RFQX-CVS124-0121 | . If there is a state change from terminal 15 ON to terminal 15 OFF while a server exchanges diagnostic messages with the client within the DefaultSession, the server stops the communications with the client after sending the complete response to the last request. | CVS124.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 30 / page 30 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0332_28 RFQX: RFQX-CVS124-0122 | . Applies to terminal 30 powered servers: If the client requests an ECUReset with the sub-function KeyOffOnReset (0x02) in the ExtendedSession in the application software, a change to the DefaultSession is performed. | CVS124.pdf | Software | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 30 / page 30 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0333_29 RFQX: RFQX-CVS124-0123 | . Applies to terminal 30 powered servers: If the client requests an ECUReset with the sub-function KeyOffOnReset (0x02) in the DefaultSession in the application software, the server accepts the request and remains in the DefaultSession. | CVS124.pdf | Software | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 30 / page 30 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0334_30 RFQX: RFQX-CVS124-0124 | . If the client requests an ECUReset (0x11) with the sub-function HardReset (0x01) in a DefaultSession in the application software, a restart is performed. | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 30 / page 30 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0335_31 RFQX: RFQX-CVS124-0125 | . If the client requests an ECUReset (0x11) with the sub-function HardReset (0x01) in the ExtendedSession in the application software a restart is performed. | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 30 / page 30 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0336_32 RFQX: RFQX-CVS124-0126 | . If the client requests an ECUReset (0x11) with the sub-function KeyOffOnReset (0x02) in the DefaultSession in the boot loader, the reset is performed. | CVS124.pdf | Software | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 30 / page 30 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0337_33 RFQX: RFQX-CVS124-0127 | . If the client requests an ECUReset (0x11) with the sub-function KeyOffOnReset (0x02) in a Non-DefaultSession in the boot loader, the reset is performed. | CVS124.pdf | Software | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 30 / page 30 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0328 RFQX: RFQX-CVS124-0128 | 24. | CVS124.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 30 / page 30 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0052 RFQX: RFQX-CVS124-0129 | Project specific DID shall be added to ranges defined as system supplier specific in ISO 14229 | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 31 / page 31 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0053 RFQX: RFQX-CVS124-0130 | 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. | CVS124.pdf | Hardware | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 31 / page 31 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| INFO_UDS_0009 RFQX: RFQX-CVS124-0131 | Table 41 – Data identifier (DID) ranges Byte value Description 0x0611-0x0620 Reserved for collective data identifiers 0xB000 – 0xB1FF Reserved for TRATON 0xCF00 – 0xCFFF TRATON data field identifiers 0xF010 disableDiagnosticClient 5.4.1 Integrity Validation Data DIDs (IVD-DIDs) Refer to VehSec_IVD_ECU for detailed requirements on Integrity Validation Data (IVD) for ECUs which need to be compliant to UNECE R156 regulation. | CVS124.pdf | System | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 31 / page 31 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0054 RFQX: RFQX-CVS124-0132 | These ECUs shall implement the following DIDs according to Table 42. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 31 / page 31 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0055 RFQX: RFQX-CVS124-0133 | The SPRMIB shall be supported for services as specified in (ISO 14229-1). | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 32 / page 32 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0056 RFQX: RFQX-CVS124-0134 | 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. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 32 / page 32 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0342 RFQX: RFQX-CVS124-0135 | Negative response code 0x22, conditionsNotCorrect , shall be used if a service request is denied due to insufficient rights according to the RBACC check. | CVS124.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 32 / page 32 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0239 RFQX: RFQX-CVS124-0136 | 5.5.1.1.1 Request parameter diagnosticSessionType | CVS124.pdf | System | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 32 / page 32 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0057 RFQX: RFQX-CVS124-0137 | 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. | CVS124.pdf | Software | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 32 / page 32 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS124-0138 RFQX: RFQX-CVS124-0138 | The application shall respond with NRC 0x22 (conditionsNotCorrect) if communication has not been switched off. | CVS124.pdf | Software | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS124 > Page 32 / page 32 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0058 RFQX: RFQX-CVS124-0139 | Table 43 – Service 0x10 request parameter diagnosticSessionType description Hex (bit 6-0) Description Cvt 0x01 defaultSession M 0x02 ProgrammingSession M 0x03 extendedDiagnosticSession M | CVS124.pdf | Software | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 32 / page 32 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0059 RFQX: RFQX-CVS124-0140 | Following an accepted request to switch to the ProgrammingSession, the application shall make all preparations to guarantee trouble-free programming operation. | CVS124.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 32 / page 32 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS124-0141 RFQX: RFQX-CVS124-0141 | 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. | CVS124.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS124 > Page 32 / page 32 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_UDS_0060 RFQX: RFQX-CVS124-0142 | 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. | CVS124.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 32 / page 32 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RFQX-CVS124-0143 RFQX: RFQX-CVS124-0143 | Its upto the ECU to include the conditions that are relevant for that particular ECU, but needs to be agreed with Vehicle Manufacturer. | CVS124.pdf | Hardware | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 32 / page 32 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0240 RFQX: RFQX-CVS124-0144 | Positive response | CVS124.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 5.5.1.2 Positive response / page 33 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0061 RFQX: RFQX-CVS124-0145 | Positive response shall be sent before the actual switch in case switching to Programming session. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 33 / page 33 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0241 RFQX: RFQX-CVS124-0146 | Response parameter diagnosticSessionType shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 5.5.1.2.1 Response parameter diagnosticSessionType / page 33 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0242 RFQX: RFQX-CVS124-0147 | Response parameter sessionParameterRecord shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 5.5.1.2.2 Response parameter sessionParameterRecord / page 33 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0243 RFQX: RFQX-CVS124-0148 | 5.5.2 ECUReset (0x11) service | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 33 / page 33 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0062 RFQX: RFQX-CVS124-0149 | An ECUReset shall not be executed if the vehicle safety can be compromised. | CVS124.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 33 / page 33 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0063 RFQX: RFQX-CVS124-0150 | ECU shall execute the reset only after sending a positive response to the ECU reset service | CVS124.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 33 / page 33 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0064 RFQX: RFQX-CVS124-0151 | 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. | CVS124.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 33 / page 33 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0065 RFQX: RFQX-CVS124-0152 | The server shall be available for ECU identification within one second after sending positive response message to an ECUReset request. | CVS124.pdf | Hardware | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 33 / page 33 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_UDS_0066 RFQX: RFQX-CVS124-0153 | After ECU reset, ECU shall be restarted and re-initialized within 2sec. | CVS124.pdf | Hardware | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 33 / page 33 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0067 RFQX: RFQX-CVS124-0154 | 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. | CVS124.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 33 / page 33 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_UDS_0244 RFQX: RFQX-CVS124-0155 | 5.5.2.1.1 Request parameter resetType | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 34 / page 34 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0068 RFQX: RFQX-CVS124-0156 | 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 | CVS124.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 34 / page 34 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0069 RFQX: RFQX-CVS124-0157 | 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. | CVS124.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 34 / page 34 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RFQX-CVS124-0158 RFQX: RFQX-CVS124-0158 | the disconnect from the battery shall not be simulated. | CVS124.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS124 > Page 34 / page 34 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS124-0159 RFQX: RFQX-CVS124-0159 | The implementation of hardReset shall first ensure that data corruption will not occur. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS124 > Page 34 / page 34 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0070 RFQX: RFQX-CVS124-0160 | 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. | CVS124.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 34 / page 34 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| REQ_UDS_0071 RFQX: RFQX-CVS124-0161 | The implementation of ECUReset service with requestParameter value 0x02 (keyOffOnReset) shall ensure that every server task is finished prior sending a positive response. | CVS124.pdf | Software | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 34 / page 34 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_UDS_0072 RFQX: RFQX-CVS124-0162 | 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. | CVS124.pdf | Software | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 34 / page 34 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| INFO_UDS_0010 RFQX: RFQX-CVS124-0163 | The server shall send an ECUReset positive response message after the server tasks above are finished but before the server performs the actual resetType. | CVS124.pdf | IT / backend | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 34 / page 34 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0073 RFQX: RFQX-CVS124-0164 | Table 45 – Service 0x11 positive response parameter description 1 ECUReset Response SID M 2 resetType M | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.5.2.2 Positive response / page 34 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0245 RFQX: RFQX-CVS124-0165 | Response parameter resetType shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 35 / page 35 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0246 RFQX: RFQX-CVS124-0166 | 5.5.2.3.1 Supported negative response codes | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 35 / page 35 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0074 RFQX: RFQX-CVS124-0167 | Table 46 – Service 0x11 negative response codes NRC Description and scenario 0x12 sub-functionNotSupported Refer to ISO 14229-1 for scenario. | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 35 / page 35 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0075 RFQX: RFQX-CVS124-0168 | Servers involved in engine start shall not process CommunicationControl service requests until 2 seconds after terminal 15 goes active. | CVS124.pdf | Software | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 5.5.3 CommunicationControl (0x28) service / page 35 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RFQX-CVS124-0169 RFQX: RFQX-CVS124-0169 | 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). | CVS124.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS124 > Page 35 / page 35 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| INFO_UDS_0011 RFQX: RFQX-CVS124-0170 | This requirement mitigates DOS (Denial Of Service) attacks | CVS124.pdf | Software | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 35 / page 35 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0076 RFQX: RFQX-CVS124-0171 | 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 | CVS124.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 35 / page 35 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_UDS_0077 RFQX: RFQX-CVS124-0172 | Safety conditions are project specific and shall be checked before accepting a request to disable communication. | CVS124.pdf | System | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 35 / page 35 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| INFO_UDS_0012 RFQX: RFQX-CVS124-0173 | After receiving CommunicationControl service request, ECUs could still keep sending some networks messages/signals to keep a healthy vehicle system. | CVS124.pdf | Software | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 35 / page 35 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0248 RFQX: RFQX-CVS124-0174 | Negative response | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.5.3.3 Negative response / page 36 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| INFO_UDS_0013 RFQX: RFQX-CVS124-0175 | 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. | CVS124.pdf | Software | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 36 / page 36 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0078 RFQX: RFQX-CVS124-0176 | 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 | CVS124.pdf | Software | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 36 / page 36 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0079 RFQX: RFQX-CVS124-0177 | 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 | CVS124.pdf | Software | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 36 / page 36 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0080 RFQX: RFQX-CVS124-0178 | 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 | CVS124.pdf | Software | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 36 / page 36 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0247 RFQX: RFQX-CVS124-0179 | 5.5.3.3 Negative response | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 36 / page 36 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0081 RFQX: RFQX-CVS124-0180 | If the parameter suppressPosRespMsgIndicationBit = true in a functionally addressed request message, the service request shall not influence any ongoing physically addressed service | CVS124.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 37 / page 37 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| INFO_UDS_0014 RFQX: RFQX-CVS124-0181 | A functionally addressed TesterPresent may arrive at any time during another request. | CVS124.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS124 > Page 37 / page 37 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0249 RFQX: RFQX-CVS124-0182 | Request format and parameter shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 5.5.4.2 Request / page 37 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0250 RFQX: RFQX-CVS124-0183 | 5.5.4.4 Negative response | CVS124.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 37 / page 37 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0251 RFQX: RFQX-CVS124-0184 | 5.5.5 ControlDTCSetting (0x85) service | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 37 / page 37 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0343 RFQX: RFQX-CVS124-0185 | Servers shall reject a ControlDTCSetting service request (DTC setting type = off) with NRC 0x22 (conditionsNotCorrect) if programming preconditions are not satisfied. | CVS124.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 37 / page 37 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_UDS_0344 RFQX: RFQX-CVS124-0186 | 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). | CVS124.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 37 / page 37 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| REQ_UDS_0345 RFQX: RFQX-CVS124-0187 | Refer to ISO 14229-1 for request format. | CVS124.pdf | Process / compliance | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 5.5.5.1 Request / page 37 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0346 RFQX: RFQX-CVS124-0188 | Refer to ISO 14229-1 for request parameter DTCSettingType. | CVS124.pdf | Process / compliance | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 5.5.5.1.1 Request parameter DTCSettingType / page 37 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0347 RFQX: RFQX-CVS124-0189 | Request parameter DTCSettingControlOptionRecord | CVS124.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 5.5.5.1.2 Request parameter DTCSettingControlOptionRecord / page 38 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0348 RFQX: RFQX-CVS124-0190 | Refer to ISO 14229-1 for positive response format and parameter. | CVS124.pdf | Process / compliance | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 5.5.5.2 Positive response / page 38 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0349 RFQX: RFQX-CVS124-0191 | Refer to ISO 14229-1 for negative response format and codes. | CVS124.pdf | Process / compliance | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 5.5.5.3 Negative response / page 38 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0082 RFQX: RFQX-CVS124-0192 | The server shall be able to switch baud rate within one second. | CVS124.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 5.5.6 Link Control (0x87) service / page 38 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_UDS_0083 RFQX: RFQX-CVS124-0193 | The boot loader shall inherit the selected baud rate if the LinkControl service request was received when the server was executing in the application. | CVS124.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 38 / page 38 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| INFO_UDS_0015 RFQX: RFQX-CVS124-0194 | Link Control (0x87) service is only applicable to CAN & CAN FD. | CVS124.pdf | Software | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 38 / page 38 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0084 RFQX: RFQX-CVS124-0195 | Positive response shall be sent before the actual switch of the baud-rate takes place. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 38 / page 38 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0254 RFQX: RFQX-CVS124-0196 | Request | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.5.7.1 Request / page 39 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0085 RFQX: RFQX-CVS124-0197 | 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 | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 39 / page 39 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0086 RFQX: RFQX-CVS124-0198 | 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. | CVS124.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 39 / page 39 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0252 RFQX: RFQX-CVS124-0199 | 5.5.6.4 Negative Response | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 39 / page 39 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0253 RFQX: RFQX-CVS124-0200 | 5.5.7 ReadDataByIdentifier (0x22) service 5.5.7.1 Request | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 39 / page 39 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0087 RFQX: RFQX-CVS124-0201 | If ECU supports request containing more than one data identifier it shall be documented (like in CDD, ODX etc). | CVS124.pdf | Hardware | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 39 / page 39 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0255 RFQX: RFQX-CVS124-0202 | DataIdentifier parameter definition shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.5.7.1.1 Request parameter dataIdentifier / page 39 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0088 RFQX: RFQX-CVS124-0203 | The data identifier ranges specified in Table 41 shall be followed. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 40 / page 40 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0259 RFQX: RFQX-CVS124-0204 | Positive response | CVS124.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 5.5.8.2 Positive response / page 40 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0256 RFQX: RFQX-CVS124-0205 | 5.5.7.3 Negative response | CVS124.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 40 / page 40 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0257 RFQX: RFQX-CVS124-0206 | 5.5.8 WriteDataByIdentifier (0x2E) service | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 40 / page 40 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0089 RFQX: RFQX-CVS124-0207 | The sequence of writing data records with service 0x2E WriteDataByIdentifier shall be independent of any specific order | CVS124.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 40 / page 40 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0090 RFQX: RFQX-CVS124-0208 | The range of a requested dataRecord value has to be checked by the server if the DID is safety relevant. | CVS124.pdf | IT / backend | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 40 / page 40 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0091 RFQX: RFQX-CVS124-0209 | 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. | CVS124.pdf | Hardware | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 40 / page 40 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0092 RFQX: RFQX-CVS124-0210 | 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). | CVS124.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 40 / page 40 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| REQ_UDS_0093 RFQX: RFQX-CVS124-0211 | Additional client requests which start copying RAM buffer data into non-volatile memory are not allowed. | CVS124.pdf | Hardware | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 40 / page 40 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS124-0212 RFQX: RFQX-CVS124-0212 | If this action is necessary then it shall be integrated implicitly into ECU Reset (0x11) Service subfunction 0x02. | CVS124.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS124 > Page 40 / page 40 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0258 RFQX: RFQX-CVS124-0213 | Request format and parameter shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 5.5.8.1 Request / page 40 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0260 RFQX: RFQX-CVS124-0214 | 5.5.9 ClearDiagnosticInformation (0x14) service 5.5.9.1 Request | CVS124.pdf | Software | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 41 / page 41 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0261 RFQX: RFQX-CVS124-0215 | 5.5.9.1.1 Request parameter groupOfDTC | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 41 / page 41 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0262 RFQX: RFQX-CVS124-0216 | groupOfDTC parameter definition shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 41 / page 41 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0263 RFQX: RFQX-CVS124-0217 | 5.5.9.3 Negative response | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 41 / page 41 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0264 RFQX: RFQX-CVS124-0218 | 5.5.10 ReadDTCInformation (0x19) service 5.5.10.1 Request | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 41 / page 41 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0265 RFQX: RFQX-CVS124-0219 | 5.5.10.1.1 Request parameter reportType | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 41 / page 41 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0094 RFQX: RFQX-CVS124-0220 | 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 | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 41 / page 41 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0095 RFQX: RFQX-CVS124-0221 | Legislated OBD relevant ECUs have to support legislated OBD standards. | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 42 / page 42 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0266 RFQX: RFQX-CVS124-0222 | ReportNumberOfDTCByStatusMask parameter format shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.5.10.1.2 Request parameter reportNumberOfDTCByStatusMask / page 42 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0267 RFQX: RFQX-CVS124-0223 | DTCStatusMask parameter format shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.5.10.1.3 Request parameter DTCStatusMask / page 42 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0096 RFQX: RFQX-CVS124-0224 | 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 | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 42 / page 42 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0097 RFQX: RFQX-CVS124-0225 | It shall be mandatory to utilize SPNs & FMIs according to SAE J1939. | CVS124.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 42 / page 42 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_UDS_0268 RFQX: RFQX-CVS124-0226 | DTCSnapshotRecordNumber parameter format shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.5.10.1.5 Request parameter DTCSnapshotRecordNumber / page 42 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0098 RFQX: RFQX-CVS124-0227 | 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 | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 43 / page 43 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0269 RFQX: RFQX-CVS124-0228 | Response parameter FunctionalGroupIdentifier shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 43 / page 43 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0270 RFQX: RFQX-CVS124-0229 | DTCSeverityMaskRecord parameter format shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.5.10.1.8 Request parameter DTCSeverityMaskRecord / page 43 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0271 RFQX: RFQX-CVS124-0230 | DTCSeverityMask parameter format shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.5.10.1.9 Request parameter DTCSeverityMask / page 43 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0272 RFQX: RFQX-CVS124-0231 | 5.5.10.2.1 Response parameter DTCStatusAvailabilityMask | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 43 / page 43 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0273 RFQX: RFQX-CVS124-0232 | Response parameter DTCStatusAvailabilityMask shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 43 / page 43 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0274 RFQX: RFQX-CVS124-0233 | Response parameter DTCFormatIdentifier shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.5.10.2.2 Response parameter DTCFormatIdentifier / page 43 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0275 RFQX: RFQX-CVS124-0234 | Response parameter DTCCount shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 5.5.10.2.3 Response parameter DTCCount / page 43 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0276 RFQX: RFQX-CVS124-0235 | Response parameter DTCAndStatusRecord shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 44 / page 44 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0277 RFQX: RFQX-CVS124-0236 | Response parameter DTCRecord shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.5.10.2.5 Response parameter DTCRecord / page 44 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS124-0237 RFQX: RFQX-CVS124-0237 | 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. | CVS124.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS124 > Page 44 / page 44 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0099 RFQX: RFQX-CVS124-0238 | 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. | CVS124.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 44 / page 44 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS124-0239 RFQX: RFQX-CVS124-0239 | If a mechanic is working on the vehicle, the driveline shall report Not Ready and place the vehicle in the state PropulsionNotReady. | CVS124.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS124 > Page 46 / page 46 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS124-0240 RFQX: RFQX-CVS124-0240 | 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. | CVS124.pdf | Hardware | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 49 / page 49 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS124-0241 RFQX: RFQX-CVS124-0241 | 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. | CVS124.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS124 > Page 50 / page 50 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0304 RFQX: RFQX-CVS124-0242 | DTCSnapshotRecordNumber#1 & DTCSnapshotRecordNumber#2 shall correspond to first time DTC happened and latest time DTC happened correspondingly. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 50 / page 50 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0100 RFQX: RFQX-CVS124-0243 | 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 | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 51 / page 51 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0101 RFQX: RFQX-CVS124-0244 | The extended data sub-function (0x06) shall have the positive response message data and format specified in Table 68. | CVS124.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 51 / page 51 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS124-0245 RFQX: RFQX-CVS124-0245 | 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. | CVS124.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS124 > Page 51 / page 51 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS124-0246 RFQX: RFQX-CVS124-0246 | 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. | CVS124.pdf | Hardware | Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS124 > Page 52 / page 52 Pre-analysis Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS124-0247 RFQX: RFQX-CVS124-0247 | For these ECUs these bytes shall contain default value 0xFF (all bytes). | CVS124.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS124 > Page 52 / page 52 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS124-0248 RFQX: RFQX-CVS124-0248 | 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). | CVS124.pdf | System | Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS124 > Page 53 / page 53 Pre-analysis Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RFQX-CVS124-0249 RFQX: RFQX-CVS124-0249 | 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. | CVS124.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS124 > Page 53 / page 53 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0278 RFQX: RFQX-CVS124-0250 | Response parameter FunctionalGroupIdentifier shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 5.5.10.2.9 Response parameter FunctionalGroupIdentifier / page 53 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0279 RFQX: RFQX-CVS124-0251 | Response parameter DTCSeverityAvailabilityMask shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 5.5.10.2.10 Response parameter DTCSeverityAvailabilityMask / page 53 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0280 RFQX: RFQX-CVS124-0252 | Response parameter DTCAndSeverityRecord shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 54 / page 54 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0281 RFQX: RFQX-CVS124-0253 | 5.5.10.3.1 Supported negative response codes | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 54 / page 54 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0282 RFQX: RFQX-CVS124-0254 | Negative response codes shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 54 / page 54 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0283 RFQX: RFQX-CVS124-0255 | 5.5.11.1.1 Request parameter dataIdentifier | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 54 / page 54 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0102 RFQX: RFQX-CVS124-0256 | The data identifier ranges specified in ISO 14229-1 shall be followed. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 54 / page 54 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0103 RFQX: RFQX-CVS124-0257 | Table 58 – Service 0x2F request parameter controlOptionRecord description 1 inputOutputControlParameter M 2 .. | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.5.11.1.2 Request parameter controlOptionRecord / page 54 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0104 RFQX: RFQX-CVS124-0258 | Table 59 – Service 0x2F request parameter inputOutputControlParameter description 0x00 returnControlToECU Refer to ISO 14229-1 for parameter description. | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 2 + (m-1) controlState byte 1 : controlState byte m C : C 5.5.11.1.3 Request parameter inputOutputControlParameter / page 54 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0284 RFQX: RFQX-CVS124-0259 | ControlEnableMaskRecord parameter format shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page M 5.5.11.1.4 Request parameter controlEnableMaskRecord / page 55 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0285 RFQX: RFQX-CVS124-0260 | 5.5.11.3 Negative response | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 55 / page 55 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0286 RFQX: RFQX-CVS124-0261 | 5.5.12 RoutineControl (0x31) service 5.5.12.1 Request | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 55 / page 55 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0287 RFQX: RFQX-CVS124-0262 | 5.5.12.1.1 Request parameter RoutineControlType | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 55 / page 55 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0105 RFQX: RFQX-CVS124-0263 | 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”. | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 55 / page 55 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0106 RFQX: RFQX-CVS124-0264 | Request parameter routineIdentifier shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.5.12.1.2 Request parameter RoutineIdentifier / page 55 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS124-0265 RFQX: RFQX-CVS124-0265 | The routine IDs as listed in Table 61 are reserved by TRATON and shall not be used by the system supplier. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS124 > Page 55 / page 55 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0107 RFQX: RFQX-CVS124-0266 | Table 61 – Service 0x31 request parameter RoutineIdentifier description 0x02B2 0x02B3 0x02B4 ReadStatusOfDiagnosticEventCodes | CVS124.pdf | Software | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 56 / page 56 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0288 RFQX: RFQX-CVS124-0267 | Request parameter routineControlOptionRecord shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.5.12.1.3 Request parameter RoutineControlOptionRecord / page 57 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0289 RFQX: RFQX-CVS124-0268 | 5.5.12.3 Negative response | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 57 / page 57 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0290 RFQX: RFQX-CVS124-0269 | 5.5.13 Request Download Service (0x34) | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 57 / page 57 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0108 RFQX: RFQX-CVS124-0270 | 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. | CVS124.pdf | Hardware | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 57 / page 57 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| INFO_UDS_0017 RFQX: RFQX-CVS124-0271 | 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. | CVS124.pdf | Hardware | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 57 / page 57 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0109 RFQX: RFQX-CVS124-0272 | 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). | CVS124.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 57 / page 57 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_UDS_0110 RFQX: RFQX-CVS124-0273 | 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. | CVS124.pdf | Software | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 57 / page 57 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0111 RFQX: RFQX-CVS124-0274 | 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 | CVS124.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 58 / page 58 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_UDS_0112 RFQX: RFQX-CVS124-0275 | The server shall support service request formatted according to Table 62. | CVS124.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 5.5.13.1 Request / page 58 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_UDS_0113 RFQX: RFQX-CVS124-0276 | 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 | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page M 5.5.13.2 Request parameter dataFormatIdentifier / page 58 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0114 RFQX: RFQX-CVS124-0277 | 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 | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 59 / page 59 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0115 RFQX: RFQX-CVS124-0278 | Table 65 – Positive response parameter description #1 RequestDownload Response SID M 0x74 #2 lengthFormatIdentifier M 0x20 #3.. | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 59 / page 59 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0116 RFQX: RFQX-CVS124-0279 | Table 66 – Service 0x34 response parameter lengthFormatIdentifier description 7 - 4 Length (number of bytes) of the maxNumberOfBlockLength parameter M 0x2 3 - 0 ISO reserved. | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page #4 maxNumberOfBlockLength[] = [ byte #1 (MSB) byte #2 ] M M 0xFF 0xFF 5.5.13.5 Response parameter lengthFormatIdentifier / page 59 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0117 RFQX: RFQX-CVS124-0280 | Table 67 – Service 0x35 request parameter description 1 RequestDownload Request SID M 2 dataFormatIdentifier M 3 addressAndLengthFormatIdentifier M 4 .. (m-1)+4 | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 60 / page 60 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0118 RFQX: RFQX-CVS124-0281 | 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 | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page M 5.5.14.1.1 Request parameter dataFormatIdentifier / page 60 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0295 RFQX: RFQX-CVS124-0282 | Request | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.5.15.1 Request / page 61 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0119 RFQX: RFQX-CVS124-0283 | 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 | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 61 / page 61 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0291 RFQX: RFQX-CVS124-0284 | MemoryAddress parameter definition shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 61 / page 61 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0292 RFQX: RFQX-CVS124-0285 | MemorySize parameter definition shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.5.14.1.4 Request parameter memorySize / page 61 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0293 RFQX: RFQX-CVS124-0286 | 5.5.14.2.1 Response parameter lengthFormatIdentifier | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 61 / page 61 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0120 RFQX: RFQX-CVS124-0287 | Table 70 – Service 0x35 response parameter lengthFormatIdentifier description 7 - 4 Length (number of bytes) of the maxNumberOfBlockLength parameter M 0x2 3 - 0 ISO reserved. | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 61 / page 61 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0294 RFQX: RFQX-CVS124-0288 | Refer to ISO 14229-1 for negative response format and codes shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page M 0 5.5.14.3 Negative response / page 61 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0296 RFQX: RFQX-CVS124-0289 | MemoryAddress parameter definition shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 62 / page 62 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0297 RFQX: RFQX-CVS124-0290 | MemorySize parameter definition shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.5.15.1.2 Request parameter transferRequestParameterRecord / page 62 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0298 RFQX: RFQX-CVS124-0291 | 5.5.15.3 Negative response | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 62 / page 62 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0299 RFQX: RFQX-CVS124-0292 | 5.5.15.3.1 Supported negative response codes | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 62 / page 62 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0300 RFQX: RFQX-CVS124-0293 | 5.5.16 RequestTransferExit (0x37) service 5.5.16.1 Request | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 62 / page 62 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0121 RFQX: RFQX-CVS124-0294 | Table 71 – Service 0x37 request parameter description 1 RequestTransferExit Request SID M 5.5.16.1.1 Request parameter transferRequestParameterRecord | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 62 / page 62 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0122 RFQX: RFQX-CVS124-0295 | The transferRequestParameterRecord shall not be supported. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 62 / page 62 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0123 RFQX: RFQX-CVS124-0296 | Table 72 – Service 0x37 positive response parameter description 1 RequestTransferExit Response SID M | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.5.16.2 Positive response / page 62 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0124 RFQX: RFQX-CVS124-0297 | The transferRequestParameterRecord shall not be supported. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 63 / page 63 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0301 RFQX: RFQX-CVS124-0298 | 5.5.16.3.1 Supported negative response codes | CVS124.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 63 / page 63 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0302 RFQX: RFQX-CVS124-0299 | 5.5.17 SecuredDataTransmission (0x84) service | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 63 / page 63 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0125 RFQX: RFQX-CVS124-0300 | This service shall be used when transmitting data in a secured mode, see CVS32. | CVS124.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 63 / page 63 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0303 RFQX: RFQX-CVS124-0301 | 5.5.17.1.1 Request message data-parameter definition | CVS124.pdf | Interface | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 63 / page 63 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0126 RFQX: RFQX-CVS124-0302 | Data parameter definition shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 63 / page 63 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0127 RFQX: RFQX-CVS124-0303 | Positive response shall be as per CVS32. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 5.5.17.2 Positive response / page 63 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0128 RFQX: RFQX-CVS124-0304 | Negative response shall be as per CVS32 5.5.17.3.1 Supported negative response codes | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 63 / page 63 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0129 RFQX: RFQX-CVS124-0305 | Negative response format shall be as per ISO 14229-1 5.5.18 Authentication (0x29) service | CVS124.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 63 / page 63 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0130 RFQX: RFQX-CVS124-0306 | Authentication (0x29) service shall be used for authentication of client and server. | CVS124.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 63 / page 63 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_UDS_0133 RFQX: RFQX-CVS124-0307 | The Authentication (0x29) service shall be implemented according to CVS31 . | CVS124.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 64 / page 64 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0134 RFQX: RFQX-CVS124-0308 | Refer to CVS31 . | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.5.18.1 Request / page 64 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0135 RFQX: RFQX-CVS124-0309 | Refer to CVS31 . | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.5.18.2 Request parameter subFunction / page 64 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0136 RFQX: RFQX-CVS124-0310 | Refer to CVS31 . | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.5.18.3 Positive response / page 64 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0137 RFQX: RFQX-CVS124-0311 | 5.5.18.4.1 Supported negative response codes | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 64 / page 64 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0138 RFQX: RFQX-CVS124-0312 | Supported negative response codes shall be as per ISO 14229-1, especially the NRC range 0x50 – 0x5D according to Table 73. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 64 / page 64 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0139 RFQX: RFQX-CVS124-0313 | For detailed error cases and the mapping to the corresponding NRCs the Authentication service implementation specification CVS31 shall be used. | CVS124.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | High | Analysis detailsSource section/page CVS124 > Page 65 / page 65 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0140 RFQX: RFQX-CVS124-0314 | 5.5.19.2 Request Parameter modeOfOperation | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 65 / page 65 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0141 RFQX: RFQX-CVS124-0315 | 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. | CVS124.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 65 / page 65 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS124-0316 RFQX: RFQX-CVS124-0316 | If the file is not stored at the location the file shall be added. | CVS124.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS124 > Page 65 / page 65 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS124-0317 RFQX: RFQX-CVS124-0317 | M 0x04 ReadFile This value shall be used to read the file (upload) at the location defined by the filePathAndName parameter. | CVS124.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS124 > Page 65 / page 65 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS124-0318 RFQX: RFQX-CVS124-0318 | U 0x05 ReadDir This value shall be used to read the directory defined in the filePathAndName parameter. | CVS124.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS124 > Page 65 / page 65 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS124-0319 RFQX: RFQX-CVS124-0319 | U 0x06 ResumeFile This value shall be used to resume downloading the file defined in the filePathAndName parameter at the returned filePosition indicator. | CVS124.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS124 > Page 65 / page 65 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS124-0320 RFQX: RFQX-CVS124-0320 | The file specified in the filePathAndName shall already exist in the ECU’s file system. | CVS124.pdf | Hardware | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS124 > Page 65 / page 65 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0142 RFQX: RFQX-CVS124-0321 | Refer to ISO 14229-1 for parameter sub-function format shall be as per ISO 14229-1. | CVS124.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 66 / page 66 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0143 RFQX: RFQX-CVS124-0322 | 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 | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 66 / page 66 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0144 RFQX: RFQX-CVS124-0323 | 5.5.19.6 Negative response | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 66 / page 66 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0145 RFQX: RFQX-CVS124-0324 | 5.5.19.7 Supported negative response codes | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 66 / page 66 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0146 RFQX: RFQX-CVS124-0325 | Supported negative response codes shall be as per ISO 14229-1. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 66 / page 66 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| INFO_UDS_0018 RFQX: RFQX-CVS124-0326 | This RoutineIdentifier enables the client to query the state of the programming preconditions in the server and applicable only for programmable ECUs. | CVS124.pdf | IT / backend | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 5.6 Routine Identifier Requirements 5.6.1 Routine 0x2203 – CheckProgrammingPreConditions / page 66 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0147 RFQX: RFQX-CVS124-0327 | The programming preconditions shall be agreed with the vehicle manufacturer. Preconditions to | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 67 / page 67 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS124-0328 RFQX: RFQX-CVS124-0328 | Preconditions to be discussed with the vehicle manufacturer shall include but not be limited to Diag safe state conditions. | CVS124.pdf | System | Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS124 > Page 67 / page 67 Pre-analysis Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_UDS_0148 RFQX: RFQX-CVS124-0329 | The decision on conditions of the programming precondition shall be based on minimum two independent sources of information. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 67 / page 67 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0149 RFQX: RFQX-CVS124-0330 | If information is not available for checking a programming precondition the programming precondition shall be considered fulfilled. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 67 / page 67 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS124-0331 RFQX: RFQX-CVS124-0331 | If the ECU received the information related to any of the conditions during the same driving cycle then it shall use that information. | CVS124.pdf | Hardware | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS124 > Page 67 / page 67 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0150 RFQX: RFQX-CVS124-0332 | This routine shall be supported in Extended session of both Application and Boot. | CVS124.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 67 / page 67 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0151 RFQX: RFQX-CVS124-0333 | Request parameter RoutineControlOptionRecord shall not be supported. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.6.1.1 Request 5.6.1.2 Request parameter RoutineControlOptionRecord / page 67 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0152 RFQX: RFQX-CVS124-0334 | Request parameter routineControlType with value 0x03 (requestRoutineResults) shall not be supported. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 67 / page 67 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0153 RFQX: RFQX-CVS124-0335 | 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 | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 67 / page 67 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0154 RFQX: RFQX-CVS124-0336 | Each routineStatus byte shall represent one not satisfied precondition according to Table 18 (see definition of “Satisfied programming precondition”). | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 67 / page 67 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0155 RFQX: RFQX-CVS124-0337 | Which ones of the programming precondition codes in Table 18 that need to be supported shall | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 68 / page 68 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0156 RFQX: RFQX-CVS124-0338 | If all preconditions are satisfied, no routineStatus byte shall be reported. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 68 / page 68 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0157 RFQX: RFQX-CVS124-0339 | Programming preconditions that do not map to one of the entries in Table 77 shall be discussed with the vehicle manufacturer. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 68 / page 68 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS124-0340 RFQX: RFQX-CVS124-0340 | 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 .. | CVS124.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS124 > Page 68 / page 68 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0158 RFQX: RFQX-CVS124-0341 | 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. | CVS124.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 69 / page 69 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| INFO_UDS_0020 RFQX: RFQX-CVS124-0342 | 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. | CVS124.pdf | Hardware | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS124 > Page 69 / page 69 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0159 RFQX: RFQX-CVS124-0343 | 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. | CVS124.pdf | Hardware | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 69 / page 69 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| INFO_UDS_0021 RFQX: RFQX-CVS124-0344 | SUV2_INFO 114 in CVS123 prevents the scenario of erasing the copied bootloader while boot loader update and leaving the ECU without any bootloader. | CVS124.pdf | Hardware | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS124 > Page 69 / page 69 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0160 RFQX: RFQX-CVS124-0345 | 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 | CVS124.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 70 / page 70 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_UDS_0161 RFQX: RFQX-CVS124-0346 | The erasing of memory shall not prevent the client from starting a data transfer using the TransferData (0x36) service, i.e. | CVS124.pdf | Software | Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 70 / page 70 Pre-analysis Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS124-0347 RFQX: RFQX-CVS124-0347 | the erasing of memory shall proceed in parallel with data transfer in case for ECUs implementing Automatic erase. | CVS124.pdf | Hardware | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS124 > Page 70 / page 70 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0162 RFQX: RFQX-CVS124-0348 | This routine shall be supported in Programming session. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 70 / page 70 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0163 RFQX: RFQX-CVS124-0349 | 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. | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.6.2.1 Request / page 70 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0164 RFQX: RFQX-CVS124-0350 | Request parameter routineControlType with value 0x03 (requestRoutineResults) shall not be supported 5.6.2.2 Request parameter addressAndLengthFormatIdentifier | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 71 / page 71 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0165 RFQX: RFQX-CVS124-0351 | 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. | CVS124.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 71 / page 71 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SUV2_REQ 62 RFQX: RFQX-CVS124-0352 | 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 & & | CVS124.pdf | Software | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 71 / page 71 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| SUV2_REQ 63 RFQX: RFQX-CVS124-0353 | in CVS123. | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 71 / page 71 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0166 RFQX: RFQX-CVS124-0354 | 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 ... | CVS124.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 71 / page 71 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0167 RFQX: RFQX-CVS124-0355 | 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 | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 255 – System specific 5.6.2.3 Positive response / page 71 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0168 RFQX: RFQX-CVS124-0356 | The routineResult byte values shall be as specified in Table 81. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 72 / page 72 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| INFO_UDS_0022 RFQX: RFQX-CVS124-0357 | 5.6.2.5 Message flow example(s) RoutineControl (EraseMemory) Example #1: Request: client → server | CVS124.pdf | IT / backend | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 72 / page 72 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| INFO_UDS_0023 RFQX: RFQX-CVS124-0358 | This is an example where the client requests to erase a module in the server memory by a given memoryStartAddress and memorySize. | CVS124.pdf | Hardware | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 72 / page 72 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| INFO_UDS_0024 RFQX: RFQX-CVS124-0359 | This example reports a failure when the erase operation is started, e.g. memory failure. | CVS124.pdf | Hardware | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 73 / page 73 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| INFO_UDS_0025 RFQX: RFQX-CVS124-0360 | This is an example where the client requests to erase a module with module index 3 in the server’s memory. | CVS124.pdf | Hardware | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 73 / page 73 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0169 RFQX: RFQX-CVS124-0361 | The RoutineIdentifier may verify the authenticity of the received file package. See CVS123 and | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 74 / page 74 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0170 RFQX: RFQX-CVS124-0362 | If authenticity verification is valid the server shall initiate all necessary steps for installation of the received file. | CVS124.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 74 / page 74 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| INFO_UDS_0026 RFQX: RFQX-CVS124-0363 | The authenticity verification performed by the RoutineIdentifier 0x2401 Software Installation does not exempt the authenticity verification for RoutineIdentifier 0xFF01 – CheckProgrammingDependencies. | CVS124.pdf | Software | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 74 / page 74 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0171 RFQX: RFQX-CVS124-0364 | The server shall send a response to RoutineIdentifier 0x2401 Software Installation without any further inputs from the client. | CVS124.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 74 / page 74 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_UDS_0172 RFQX: RFQX-CVS124-0365 | 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). | CVS124.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 74 / page 74 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_UDS_0173 RFQX: RFQX-CVS124-0366 | This routine shall be supported in Programming session. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 74 / page 74 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0174 RFQX: RFQX-CVS124-0367 | Request parameter RoutineControlOptionRecord shall not be supported. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.6.3.1 Request / page 74 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0175 RFQX: RFQX-CVS124-0368 | Positive responses to RoutineControl (Software Installation) service requests shall be formatted | CVS124.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 75 / page 75 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0176 RFQX: RFQX-CVS124-0369 | Description Cvt Values #1 RoutineControl Request SID M 0x71 #2 routineControlType (requestRoutineResults) M 0x03 #3 routineIdentifier (MSB) M 0x24 #4 routineIdentifier (LSB) M 0x01 #5 AuthenticityVerificationStatus M 0x00 – 0xFF #6 SoftwareInstallationStatus M 0x00 – 0xFF #7 CompletionPercentage M 0x00 – 0x64 #8-#9 TimeRemaningEstimative M 0x0000 – 0xFFFF AuthenticityVerificationStatus shall be formatted according to Table 90. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 75 / page 75 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0177 RFQX: RFQX-CVS124-0370 | AuthenticityVerificationStatus bit 7-6 (AuthenticityStatus) shall remain as 0x0 (Software Authenticity Invalid) until the verification completes. | CVS124.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 75 / page 75 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0178 RFQX: RFQX-CVS124-0371 | 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). | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 75 / page 75 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0179 RFQX: RFQX-CVS124-0372 | SoftwareInstallationStatus shall be formatted according to Table 91. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 76 / page 76 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0180 RFQX: RFQX-CVS124-0373 | SoftwareInstallationStatus bit 7-6 (InstallationStatus) shall remain as 0x0 (Installation On-going) until the installation completes. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 76 / page 76 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0181 RFQX: RFQX-CVS124-0374 | Table 91 – SoftwareInstallationStatus Bit Bit Name Bit Values Description 7-6 InstallationStatus 0x0: Installation On-going 0x1: Installation Successful 0x2: Installation Failed 5 - 3 InstallationFailureType 0x0: No Failures 0x1 – 0x7: Project Specific 2 ResetRequired 0x0: Reset not required 0x1: Reset required 1 - 0 Reserved Note: Shall be kept as 0x0 CompletionPercentage shall inform the progress percentage of the software has been installed in the partition memory area. | CVS124.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 76 / page 76 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS124-0375 RFQX: RFQX-CVS124-0375 | Information shall be provided in percentage. | CVS124.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS124 > Page 76 / page 76 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0182 RFQX: RFQX-CVS124-0376 | TimeRemaningEstimative shall inform the time estimative to complete the installation of the file. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 76 / page 76 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS124-0377 RFQX: RFQX-CVS124-0377 | Information shall be provided in seconds. | CVS124.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS124 > Page 76 / page 76 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| INFO_UDS_0027 RFQX: RFQX-CVS124-0378 | Implementation hint can be seen on Annex B. | CVS124.pdf | Interface | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 76 / page 76 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| INFO_UDS_0028 RFQX: RFQX-CVS124-0379 | 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. | CVS124.pdf | Software | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.6.3.3 Negative response / page 76 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| INFO_UDS_0029 RFQX: RFQX-CVS124-0380 | This RoutineIdentifier value allows the client to start a consistency check of the server and should be able to execute independent from programming sequence. | CVS124.pdf | IT / backend | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 5.6.4 Routine 0xFF01 – CheckProgrammingDependencies (check the flash programming) / page 76 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0183 RFQX: RFQX-CVS124-0381 | The server shall check whether or not the individual modules are complete and compatible with | CVS124.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 77 / page 77 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RFQX-CVS124-0382 RFQX: RFQX-CVS124-0382 | 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). | CVS124.pdf | Software | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS124 > Page 77 / page 77 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0184 RFQX: RFQX-CVS124-0383 | The method used to check compatibility/consistency shall be determined by the supplier in consultation with the vehicle manufacturer. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 77 / page 77 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0185 RFQX: RFQX-CVS124-0384 | The consistency check shall be carried out solely by the server. | CVS124.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 77 / page 77 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_UDS_0186 RFQX: RFQX-CVS124-0385 | The server shall verify the authenticity and integrity of the software as a part of the consistency check. | CVS124.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 77 / page 77 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_UDS_0187 RFQX: RFQX-CVS124-0386 | The authenticity and integrity information shall be supplied to the server before the software is updated. | CVS124.pdf | Software | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 77 / page 77 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_UDS_0188 RFQX: RFQX-CVS124-0387 | The authenticity and integrity check shall be carried out solely by the server. | CVS124.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 77 / page 77 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_UDS_0189 RFQX: RFQX-CVS124-0388 | This routine shall be supported in Programming session. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 77 / page 77 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0190 RFQX: RFQX-CVS124-0389 | The server shall support RoutineControl (CheckProgrammingDependencies) service request formatted according to Table 92. | CVS124.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 5.6.4.1 Request / page 77 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_UDS_0191 RFQX: RFQX-CVS124-0390 | Table 92 – RoutineIdentifier 0xFF01 description Byte Description Cvt Hex #1 RoutineControl Request SID M 0x31 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) M 0xFF #4 routineIdentifier (LSB) M 0x01 Request parameter routineControlType with value 0x03 (requestRoutineResults) shall not be supported. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 77 / page 77 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0192 RFQX: RFQX-CVS124-0391 | Positive responses to RoutineControl (CheckProgrammingDependencies) service requests shall be formatted according to Table 93. | CVS124.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 78 / page 78 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0193 RFQX: RFQX-CVS124-0392 | Table 93 – RoutineControl (CheckProgrammingDependencies) positive response format #1 RoutineControl Response SID M 0x71 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) checkProgrammingDependencies[byte#1] M 0xFF #4 routineIdentifier (LSB) checkProgrammingDependencies [byte#2] M 0x01 #5 routineStatus routineResult M 0x00-0xFF Parameter routineResult shall adopt one of the values specified in Table 94. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 78 / page 78 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| INFO_UDS_0030 RFQX: RFQX-CVS124-0393 | 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 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. | CVS124.pdf | Software | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 78 / page 78 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| INFO_UDS_0031 RFQX: RFQX-CVS124-0394 | This is an example where the client requests CheckProgrammingDependencies to finalize the validation after software download. | CVS124.pdf | Software | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 79 / page 79 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| INFO_UDS_0032 RFQX: RFQX-CVS124-0395 | The checksum was contained in the data stream programmed to the memory. | CVS124.pdf | Hardware | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 79 / page 79 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| INFO_UDS_0033 RFQX: RFQX-CVS124-0396 | Table 95 – Example: Request: client → server #1 RoutineControl Request SID 0x31 #2 routineControlType (StartRoutine) 0x01 #3 routineIdentifier byte#1 (checkProgrammingDependencies MSB) 0xFF #4 routineIdentifier byte#2 (checkProgrammingDependencies LSB) 0x01 Example: Positive response: server → client In this example the routine status indicates that the programming dependencies returned correct result. | CVS124.pdf | IT / backend | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 79 / page 79 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0194 RFQX: RFQX-CVS124-0397 | Table 96 – Positive response: server → client #1 RoutineControl Response SID 0x71 #2 routineControlType (StartRoutine) 0x01 #3 routineIdentifier byte#1 (checkProgrammingDependencies MSB) 0xFF #4 routineIdentifier byte#2 (checkProgrammingDependencies LSB) 0x01 #5 routineStatus (routineResult) 0x00 5.6.5 Routine 0xCAFE – EMP The request and response shall be implemented according to CVS33. | CVS124.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 79 / page 79 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_UDS_0195 RFQX: RFQX-CVS124-0398 | This routine shall be supported in all sessions of Application and Boot. | CVS124.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 79 / page 79 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0196 RFQX: RFQX-CVS124-0399 | 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 | CVS124.pdf | Hardware | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 80 / page 80 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0197 RFQX: RFQX-CVS124-0400 | DTC status bits shall not make use of any vehicle manufacturer specific reset condition (e.g. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 80 / page 80 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| INFO_UDS_0034 RFQX: RFQX-CVS124-0401 | The occurrence counter is used in DTCExtDataRecords, see section 5.5.10.2.8. | CVS124.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.7.2 Occurrence counter OCC / page 80 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0198 RFQX: RFQX-CVS124-0402 | The occurrence counter minimum value shall be zero (0). | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 80 / page 80 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0199 RFQX: RFQX-CVS124-0403 | The occurrence counter maximum value shall be 126. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 80 / page 80 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0200 RFQX: RFQX-CVS124-0404 | The occurrence counter default value shall be zero (0). | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 80 / page 80 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0201 RFQX: RFQX-CVS124-0405 | The occurrence counter shall increment by one (1) only. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 80 / page 80 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0202 RFQX: RFQX-CVS124-0406 | The occurrence counter shall increment if it’s value is not at it’s maximum value already. | CVS124.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 80 / page 80 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_UDS_0203 RFQX: RFQX-CVS124-0407 | The occurrence counter shall increment at a change of DTC status bits 0 testFailed and 3 confirmedDTC both from 0 to 1. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 80 / page 80 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0204 RFQX: RFQX-CVS124-0408 | The occurrence counter shall increment at a change of DTC status bit 0 testFailed from 0 to 1, | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 81 / page 81 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0205 RFQX: RFQX-CVS124-0409 | 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. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 81 / page 81 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0206 RFQX: RFQX-CVS124-0410 | The occurrence counter value 127 shall be defined as "errors with the counter". | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 81 / page 81 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| INFO_UDS_0035 RFQX: RFQX-CVS124-0411 | The timestamp of occurrence is used at DTCExtDataRecords, see section 5.5.10.2.8. | CVS124.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 5.7.3 Timestamp of occurrence / page 81 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0207 RFQX: RFQX-CVS124-0412 | The timestamp default value shall be a 0xFF in each data. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 81 / page 81 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0208 RFQX: RFQX-CVS124-0413 | The timestamp is presented in SAE J1939-71 format without local hour/minute offsets. | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 81 / page 81 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0209 RFQX: RFQX-CVS124-0414 | 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 | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 81 / page 81 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0210 RFQX: RFQX-CVS124-0415 | The latest occurrence shall be updated at a change of DTC status bits 0 (testFailed) and 3 | CVS124.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 82 / page 82 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0210 RFQX: RFQX-CVS124-0416 | 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. | CVS124.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 82 / page 82 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0211 RFQX: RFQX-CVS124-0417 | If occurrence counter is set to 1, the timestamp of the latest occurrence shall be set to 0xFF. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 82 / page 82 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0212 RFQX: RFQX-CVS124-0418 | 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 | CVS124.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 82 / page 82 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| INFO_UDS_0036 RFQX: RFQX-CVS124-0419 | The total vehicle distance at occurrence is used in DTCExtDataRecords, see section 5.5.10.2.8. | CVS124.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS124 > Page 82 / page 82 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0213 RFQX: RFQX-CVS124-0420 | The vehicle distance shall be represented by a four byte integer, big endian, with five meter per bit (5m/bit). | CVS124.pdf | System | Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 82 / page 82 Pre-analysis Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0214 RFQX: RFQX-CVS124-0421 | If all sources of vehicle distance information present no current data, the distance information shall be set to 0xFF at all bytes. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 82 / page 82 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0215 RFQX: RFQX-CVS124-0422 | The latest distance value is updated at a change of DTC status bits 0 (testFailed) and 3 | CVS124.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 82 / page 82 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0216 RFQX: RFQX-CVS124-0423 | 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. | CVS124.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 82 / page 82 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0217 RFQX: RFQX-CVS124-0424 | The first distance value is updated at the first change of DTC status bits 0 (testFailed) and 3 | CVS124.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 5.7.4.2 First occurrence / page 82 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| INFO_UDS_0037 RFQX: RFQX-CVS124-0425 | The operational hours at occurrence is used at DTCExtDataRecords, see section 5.5.10.2.8. | CVS124.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS124 > Page 83 / page 83 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0218 RFQX: RFQX-CVS124-0426 | The operational hours are presented by a four byte integer, big endian, with , half second per bit (0,5s/bit). | CVS124.pdf | System | Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 83 / page 83 Pre-analysis Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0219 RFQX: RFQX-CVS124-0427 | If all sources of operational hours information present no current data, the operational hours information shall be set to 0xFF at all bytes. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 83 / page 83 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0220 RFQX: RFQX-CVS124-0428 | The latest operational hours value is updated at a change of DTC status bits 0 (testFailed) and 3 (confirmedDTC) both from 0 to 1. | CVS124.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 5.7.5.1 Latest occurrence / page 83 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0221 RFQX: RFQX-CVS124-0429 | 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. | CVS124.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 83 / page 83 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0222 RFQX: RFQX-CVS124-0430 | 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. | CVS124.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 5.7.5.2 First occurrence / page 83 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0223 RFQX: RFQX-CVS124-0431 | The server shall be available for complete diagnostic communication within two seconds after a power on. | CVS124.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 5.9 Performance requirements on CAN / page 83 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_UDS_0224 RFQX: RFQX-CVS124-0432 | If diagnostic data is not available in time the ECU should respond with NRC 0x78 (requestCorrectlyReceived-ResponsePending) for maximum allowed time. | CVS124.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 83 / page 83 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| RFQX-CVS124-0433 RFQX: RFQX-CVS124-0433 | for Linux based systems still running in boot, the server should indicate with DID 0xF1AD that it is running in boot. | CVS124.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 83 / page 83 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_UDS_0225 RFQX: RFQX-CVS124-0434 | For P2Server, the minimum value shall be 0 ms, a maximum value shall be 50 ms. | CVS124.pdf | System | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 5.10 Session layer performance requirements / page 83 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_UDS_0226 RFQX: RFQX-CVS124-0435 | For P2Client, a value of 150 ms shall be used. | CVS124.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 83 / page 83 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0227 RFQX: RFQX-CVS124-0436 | For P2*Server, the minimum value shall be 0ms, the maximum value shall be 4000ms. | CVS124.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 84 / page 84 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_UDS_0228 RFQX: RFQX-CVS124-0437 | For P2*Client, the value estimation given in ISO 14229-2 shall be used. | CVS124.pdf | Process / compliance | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 84 / page 84 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| REQ_UDS_0229 RFQX: RFQX-CVS124-0438 | The value for P4_Server_max shall be maximum 30 seconds. | CVS124.pdf | System | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 84 / page 84 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| REQ_UDS_0230 RFQX: RFQX-CVS124-0439 | The system supplier shall document the implemented value for P4_Server_max. | CVS124.pdf | System | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 84 / page 84 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| INFO_UDS_0039 RFQX: RFQX-CVS124-0440 | F197 structure added | CVS124.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 90 / page 90 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0339 RFQX: RFQX-CVS124-0441 | F198 Request and response format | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 90 / page 90 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0340 RFQX: RFQX-CVS124-0442 | F199 Request and response format | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 90 / page 90 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0341 RFQX: RFQX-CVS124-0443 | F19A Request and response format | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 90 / page 90 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0342 RFQX: RFQX-CVS124-0444 | NRC for RBACC check failures | CVS124.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 90 / page 90 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0343 RFQX: RFQX-CVS124-0445 | , | CVS124.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 90 / page 90 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0344 RFQX: RFQX-CVS124-0446 | , | CVS124.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 90 / page 90 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0345 RFQX: RFQX-CVS124-0447 | , | CVS124.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 90 / page 90 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0346 RFQX: RFQX-CVS124-0448 | , | CVS124.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 90 / page 90 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0347 RFQX: RFQX-CVS124-0449 | , | CVS124.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 90 / page 90 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0348 RFQX: RFQX-CVS124-0450 | , | CVS124.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 90 / page 90 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0349 RFQX: RFQX-CVS124-0451 | Requirements, Request and response formats for the ControlDTCSetting(0x85) added. | CVS124.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 90 / page 90 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0003 RFQX: RFQX-CVS124-0452 | Added semantic Identifier DIDs, changed the NodeUID DID to INTERNAL | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 90 / page 90 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0034 RFQX: RFQX-CVS124-0453 | Change in the length of NodeUID(0xF1AF) | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 90 / page 90 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| INFO_UDS_0040 RFQX: RFQX-CVS124-0454 | Change in the retrieval method for NodeUID(0xF1AF) | CVS124.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 90 / page 90 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0036 RFQX: RFQX-CVS124-0455 | 0xF1B9 RBACCIdentifierNumber is changed to Mandatory | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 90 / page 90 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0037 RFQX: RFQX-CVS124-0456 | 0xF1BA RBACCStructureVersion,bit-length changed | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS124 > Page 90 / page 90 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0045 RFQX: RFQX-CVS124-0457 | Changes for service (0x84) and (0x31) | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS124 > Page 90 / page 90 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0048 RFQX: RFQX-CVS124-0458 | Updated the document references | CVS124.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 90 / page 90 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0107 RFQX: RFQX-CVS124-0459 | 0XCAFE and 0xFF02 are updated to Mandatory | CVS124.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 90 / page 90 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0180 RFQX: RFQX-CVS124-0460 | Modifcations on the bit values and new bit added | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 90 / page 90 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0193 RFQX: RFQX-CVS124-0461 | 0x05 is changed to Mandatory 6 Normative references: Updated the referenced documents and versions Removed Requirements and infos | CVS124.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS124 > Page 90 / page 90 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0045 RFQX: RFQX-CVS124-0462 | (0x86) service removed | CVS124.pdf | Software | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 90 / page 90 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0053 RFQX: RFQX-CVS124-0463 | , | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 90 / page 90 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0054 RFQX: RFQX-CVS124-0464 | Removed the reserved DID ranges and 0xF1C1 | CVS124.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS124 > Page 90 / page 90 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| REQ_UDS_0024 RFQX: RFQX-CVS124-0465 | 0xF19E ODXFileDataIdentifier is removed 2024-10 First issue | CVS124.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS124 > Page 90 / page 90 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS151-0001 RFQX: RFQX-CVS151-0001 | 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. | CVS151.pdf | System | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS151 > Page 1 / page 1 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No supplier action - document reference / boilerplate. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS151-0002 RFQX: RFQX-CVS151-0002 | 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”. | CVS151.pdf | Process / compliance | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS151 > Page 1 / page 1 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS151-0003 RFQX: RFQX-CVS151-0003 | The User shall apply the latest version of this CVS151. | CVS151.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS151 > Page 1 / page 1 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS151-0004 RFQX: RFQX-CVS151-0004 | 1 Scope Concepts such as secure-update (CVS37) requires Role Based Access Control (RBAC) for diagnostics (UDS). | CVS151.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS151 > Page 3 / page 3 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| RBAC_INFO 1 RFQX: RFQX-CVS151-0005 | 3 Technical content 3.1 Overview Server/ECUClient/tester UDS Authorize OK/NOTOK UDS request Is the request allowed, based on the client's access rights i.e., compare the client's role/s against the RBACCOK/NOTOK Figure 1 – Overview Figure 1 shows a highlevel view of the RBAC concept. | CVS151.pdf | IT / backend | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS151 > Page 4 / page 4 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_INFO 2 RFQX: RFQX-CVS151-0006 | Before a client can execute diagnostics services that are under RBAC, the client must perform some type of authorization procedure towards the server/ECU. | CVS151.pdf | Hardware | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS151 > Page 4 / page 4 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| RBAC_INFO 3 RFQX: RFQX-CVS151-0007 | The RBAC logic is typically part of the ECU application- and boot-software. | CVS151.pdf | Software | Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS151 > Page 4 / page 4 Pre-analysis Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_INFO 4 RFQX: RFQX-CVS151-0008 | The RBACC is typically injected into the ECU during production, using a secure protocol. | CVS151.pdf | Cybersecurity | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS151 > Page 4 / page 4 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_INFO 5 RFQX: RFQX-CVS151-0009 | As previously mentioned, each ECU (supporting RBAC) will be programmed with an RBACC, RBAC Configuration, containing the rules to drive the RBAC logic. | CVS151.pdf | Software | Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 3.2 Role Based Access Control Configuration / page 4 Pre-analysis Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_INFO 6 RFQX: RFQX-CVS151-0010 | The RBACC contains one or several role-configurations (see Figure 2 for a visual representation). | CVS151.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS151 > Page 4 / page 4 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_REQ 1 RFQX: RFQX-CVS151-0011 | Each RBACC shall only contain one role-configuration per each supported role. | CVS151.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS151 > Page 4 / page 4 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| RBAC_INFO 7 RFQX: RFQX-CVS151-0012 | The Role field (in the RBACC) can be seen as a key in a dictionary, which means, two role- configurations cannot contain the same Role value. | CVS151.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS151 > Page 5 / page 5 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_INFO 8 RFQX: RFQX-CVS151-0013 | A role-configuration, in its turn, contains one or many rules (see Figure 2 for a visual representation). | CVS151.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS151 > Page 5 / page 5 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_REQ 2 RFQX: RFQX-CVS151-0014 | If conflicting/overlapping rules are found within a role-configuration, the server shall enforce that deny rule takes precedence over the allow rule. | CVS151.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS151 > Page 5 / page 5 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_INFO 9 RFQX: RFQX-CVS151-0015 | Each rule can be of either DENY or ALLOW type. | CVS151.pdf | Interface | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS151 > Page 5 / page 5 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_REQ 3 RFQX: RFQX-CVS151-0016 | If a matching allow/deny rule is found and all the rule settings are fulfilled, the server shall accept/deny the request. | CVS151.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS151 > Page 5 / page 5 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_INFO 46 RFQX: RFQX-CVS151-0017 | Considering all the rule setting fulfilled, for matching rules of allow type the server will accept the request and for matching rules of deny type the server will deny the request. | CVS151.pdf | IT / backend | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS151 > Page 5 / page 5 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_REQ 4 RFQX: RFQX-CVS151-0018 | If a matching rule is found and not all the rule settings are fulfilled, the server shall consider the request rejected for that rule. | CVS151.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS151 > Page 5 / page 5 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_REQ 5 RFQX: RFQX-CVS151-0019 | The server shall deny a request if no matching rule is found on RBACC. | CVS151.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS151 > Page 5 / page 5 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_INFO 10 RFQX: RFQX-CVS151-0020 | All RBACC ALLOW rules have a setting that dictates if a request, matching the rule, must be 14229-1:2020). | CVS151.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS151 > Page 5 / page 5 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| RBAC_INFO 11 RFQX: RFQX-CVS151-0021 | Examples of rules within a single role and their expected behaviour: Example 1: A rule in the RBACC states that a role can execute ReadDataByIdentifier 0x22 (see ISO-14229-1:2020) with Confidentiality off. | CVS151.pdf | Interface | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS151 > Page 5 / page 5 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_INFO 12 RFQX: RFQX-CVS151-0022 | The RBAC logic is based on an implicit deny principle; meaning, if the RBACC does not explicitly state that a diagnostic request is allowed or denied, then the request is implicitly denied. | CVS151.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS151 > Page 6 / page 6 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_REQ 6 RFQX: RFQX-CVS151-0023 | The server shall evaluate each role-configuration independently from each other. | CVS151.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS151 > Page 6 / page 6 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_INFO 13 RFQX: RFQX-CVS151-0024 | If conflicting/overlapping rules are found among multiple role-configuration, the server accepts the request as long within one role-configuration the request is allowed. | CVS151.pdf | IT / backend | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS151 > Page 6 / page 6 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_INFO 14 RFQX: RFQX-CVS151-0025 | Examples of two roles with overlapping rules and their expected behaviour: Example 5: The RBACC contains two roles with rules that states how the role can execute ReadDataByIdentifier 0x22 (see ISO-14229-1:2020). | CVS151.pdf | Interface | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS151 > Page 6 / page 6 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_INFO 15 RFQX: RFQX-CVS151-0026 | If a client/tester has been assigned several roles (i.e., several role-configurations in the RBACC are applicable for the client/tester), and at least one of the applicable role-configuration explicitly allows a particular request, then the request is allowed, regardless of if another applicable role-configuration explicitly denies it. | CVS151.pdf | IT / backend | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS151 > Page 6 / page 6 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_INFO 16 RFQX: RFQX-CVS151-0027 | See Annex B for a more detailed example of RBACC. | CVS151.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS151 > Page 6 / page 6 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_REQ 27 RFQX: RFQX-CVS151-0028 | The server shall require that requests are authenticated for allow rules, using e.g., SecuredDataTransmission 0x84 (see CVS31, ISO-14229-1:2020). | CVS151.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS151 > Page 6 / page 6 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_INFO 41 RFQX: RFQX-CVS151-0029 | Allow rules defined in role 0 are an exception to this requirement, see 3.13. | CVS151.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS151 > Page 6 / page 6 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_REQ 7 RFQX: RFQX-CVS151-0030 | 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)) } | CVS151.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS151 > Page 7 / page 7 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_INFO 18 RFQX: RFQX-CVS151-0031 | The version specifies the structure of RBACC. | CVS151.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page 3.4 version / page 8 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_REQ 8 RFQX: RFQX-CVS151-0032 | The server shall support in the version field two octets. | CVS151.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS151 > Page 8 / page 8 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_REQ 9 RFQX: RFQX-CVS151-0033 | The server shall support major version value 3 and minor version value 0. | CVS151.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS151 > Page 8 / page 8 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_INFO 19 RFQX: RFQX-CVS151-0034 | If other versions shall be supported is out of the scope of this document and shall be agreed upon between projects in Traton. | CVS151.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS151 > Page 8 / page 8 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| RBAC_REQ 10 RFQX: RFQX-CVS151-0035 | Before RBACC is stored, the server shall verify that the server supports the structure indicated in the version number. | CVS151.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS151 > Page 8 / page 8 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RFQX-CVS151-0036 RFQX: RFQX-CVS151-0036 | If the version number does not comply with the server implementation, the server shall reject storing the data. | CVS151.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS151 > Page 8 / page 8 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RBAC_REQ 11 RFQX: RFQX-CVS151-0037 | The server shall report the currently stored RBACC’s version via diagnostics. | CVS151.pdf | IT / backend | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS151 > Page 8 / page 8 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_INFO 35 RFQX: RFQX-CVS151-0038 | See RBACStructureVersion definition in CVS124. | CVS151.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS151 > Page 8 / page 8 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_INFO 20 RFQX: RFQX-CVS151-0039 | This field identifies the RBACC using 16 octets. | CVS151.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page 3.5 rbacc-id / page 8 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_REQ 12 RFQX: RFQX-CVS151-0040 | The server shall support 16 octets in the rbacc-id field. | CVS151.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS151 > Page 8 / page 8 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_REQ 13 RFQX: RFQX-CVS151-0041 | The server shall report the currently stored RBACC’s rbacc-id via diagnostics. | CVS151.pdf | IT / backend | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS151 > Page 8 / page 8 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_INFO 36 RFQX: RFQX-CVS151-0042 | See RBACIdentifierNumber definition in CVS124. | CVS151.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS151 > Page 8 / page 8 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_INFO 21 RFQX: RFQX-CVS151-0043 | A 32-bit unsigned integer that represents one role. | CVS151.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page 3.6 role-configuration / page 8 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_REQ 14 RFQX: RFQX-CVS151-0044 | The server shall support role-configurations using 32-bit unsigned integer. | CVS151.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS151 > Page 8 / page 8 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_REQ 15 RFQX: RFQX-CVS151-0045 | 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. | CVS151.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 3.7 pattern-rules / page 9 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_INFO 22 RFQX: RFQX-CVS151-0046 | The diagnostic pattern identifies the diagnostic request. | CVS151.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS151 > Page 9 / page 9 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_INFO 23 RFQX: RFQX-CVS151-0047 | This type of rule can be used to create rules for all types of diagnostic requests. | CVS151.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS151 > Page 9 / page 9 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_REQ 16 RFQX: RFQX-CVS151-0048 | The server shall support the pattern-rule setting according to Table 1. | CVS151.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS151 > Page 9 / page 9 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RFQX-CVS151-0049 RFQX: RFQX-CVS151-0049 | 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. | CVS151.pdf | IT / backend | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS151 > Page 9 / page 9 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_REQ 17 RFQX: RFQX-CVS151-0050 | 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. | CVS151.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 4-7 N/A Reserved for future use 3.8 did-rules / page 9 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_REQ 18 RFQX: RFQX-CVS151-0051 | The byte order for DID shall be big endian. | CVS151.pdf | System | Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS151 > Page 9 / page 9 Pre-analysis Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| RBAC_INFO 24 RFQX: RFQX-CVS151-0052 | This type of rule can be used to create rules for all types of diagnostic requests that makes use of DIDs e.g., ReadDataByIdentifier, WriteDataByIdentifier, DynamicallyDefineDataIdentifier (see ISO 14429-1:2020) etc. | CVS151.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS151 > Page 9 / page 9 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_REQ 19 RFQX: RFQX-CVS151-0053 | The server shall support the did-rule setting according to Table 2. | CVS151.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS151 > Page 9 / page 9 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RFQX-CVS151-0054 RFQX: RFQX-CVS151-0054 | 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. | CVS151.pdf | IT / backend | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS151 > Page 10 / page 10 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_REQ 20 RFQX: RFQX-CVS151-0055 | 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 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. | CVS151.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS151 > Page 10 / page 10 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_INFO 25 RFQX: RFQX-CVS151-0056 | This type of rule can be used to create rules for all types of diagnostic requests that makes use of RIDs. | CVS151.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS151 > Page 10 / page 10 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_REQ 21 RFQX: RFQX-CVS151-0057 | The server shall support the rid-rule setting according to Table 3. | CVS151.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS151 > Page 10 / page 10 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RFQX-CVS151-0058 RFQX: RFQX-CVS151-0058 | 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. | CVS151.pdf | IT / backend | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS151 > Page 11 / page 11 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_INFO 26 RFQX: RFQX-CVS151-0059 | 4 Start 0 == This rule is not applicable when the RID is being started 1 == This rule is applicable when the RID is being started 5 Stop 0 == This rule is not applicable when the RID is being stopped 1 == This rule is applicable when the RID is being stopped 6 Read-results 0 == This rule is not applicable when the RID results are being read 1 == This rule is applicable when the RID results are being read 7 N/A Reserved for future use 3.10 Extending the Role Based Access Control Configuration using a certificate It is possible to extend the rules (in the RBACC), by including an extension in the user’s/client’s certificate (when certificate-based authorization is being used). | CVS151.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS151 > Page 11 / page 11 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_REQ 22 RFQX: RFQX-CVS151-0060 | 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. | CVS151.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS151 > Page 11 / page 11 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_INFO 27 RFQX: RFQX-CVS151-0061 | A snippet from https://datatracker.ietf.org/doc/html/rfc5280#section-4.1 that specifies the layout of a certificate extension. | CVS151.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS151 > Page 11 / page 11 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_REQ 23 RFQX: RFQX-CVS151-0062 | The server shall interpret the extnValue (see snipped above) as of one instance of a RBACC (see 3.3). | CVS151.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS151 > Page 12 / page 12 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_INFO 28 RFQX: RFQX-CVS151-0063 | Inside the extnValue (see snipped above) is one instance of a RBACC (see 3.3). | CVS151.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS151 > Page 12 / page 12 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_INFO 29 RFQX: RFQX-CVS151-0064 | This feature can be particularly useful if you want to create a custom rule-set (which does not map to a role-configuration in the RBACC) for a client/tester without assigning him/her a specific role. | CVS151.pdf | Interface | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS151 > Page 12 / page 12 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS151-0065 RFQX: RFQX-CVS151-0065 | 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. | CVS151.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS151 > Page 12 / page 12 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_REQ 36 RFQX: RFQX-CVS151-0066 | The server shall exert the RBACC roles based on the ECU-diagnostics-Role extension on the client’s certificate. | CVS151.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 3.11 ECU-Diagnostics-Role Extension / page 12 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_INFO 30 RFQX: RFQX-CVS151-0067 | Figure 3 shows the interaction between the diagnostics server and the RBAC enforcer logic. | CVS151.pdf | Software | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 3.12 Logic / page 12 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_REQ 35 RFQX: RFQX-CVS151-0068 | The server shall implement RBAC internal logic as per Figure 4. | CVS151.pdf | Software | Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page Figure 3 – Logic Overview / page 13 Pre-analysis Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_INFO 32 RFQX: RFQX-CVS151-0069 | As previously stated and as show in Figure 4, deny rules takes precedence over allow rules. | CVS151.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS151 > Page 15 / page 15 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_INFO 33 RFQX: RFQX-CVS151-0070 | The RBAC logic starts the process of finding out if the client has a certificate (that extends the RBAC, see 3.10) and/or any exerted roles. | CVS151.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS151 > Page 15 / page 15 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_REQ 32 RFQX: RFQX-CVS151-0071 | The server shall implement RBAC pattern rule evaluation logic as per Figure 5. | CVS151.pdf | Software | Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS151 > Page 15 / page 15 Pre-analysis Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_INFO 34 RFQX: RFQX-CVS151-0072 | The “request.conditions COMPLIES_WITH rule.settings” refers to evaluate if the request conditions fulfils the expected rule settings. | CVS151.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS151 > Page 16 / page 16 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS151-0073 RFQX: RFQX-CVS151-0073 | E.g: For the evaluate pattern the rule setting Confidentiality is set to 0x01 (Confidentiality is required). | CVS151.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS151 > Page 16 / page 16 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes No supplier action - document reference / boilerplate. Risk / impact Limited; standard implementation and verification risk. |
| RBAC_REQ 33 RFQX: RFQX-CVS151-0074 | The server shall implement RBAC did rule evaluate as per Figure 6. | CVS151.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS151 > Page 16 / page 16 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_REQ 34 RFQX: RFQX-CVS151-0075 | The server shall implement RBAC rid rule evaluate as per Figure 7. | CVS151.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS151 > Page 17 / page 17 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_INFO 37 RFQX: RFQX-CVS151-0076 | In Figure 8, the RBAC complete rule evaluation logic is described. | CVS151.pdf | Software | Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS151 > Page 18 / page 18 Pre-analysis Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RBAC_INFO 38 RFQX: RFQX-CVS151-0077 | The role-configuration containing Role 0 is special, it specifies rules that apply to all clients (regardless of whether the client has been assigned a diagnostics role or not). | CVS151.pdf | IT / backend | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 3.13 Role 0 Specific Requirements / page 19 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS151-0078 RFQX: RFQX-CVS151-0078 | 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. | CVS151.pdf | System | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS151 > Page 19 / page 19 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| RBAC_REQ 24 RFQX: RFQX-CVS151-0079 | The server shall allow requests that are contained in role 0 rules regardless of the client authentication state. | CVS151.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS151 > Page 19 / page 19 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_REQ 25 RFQX: RFQX-CVS151-0080 | 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). | CVS151.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS151 > Page 19 / page 19 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_REQ 26 RFQX: RFQX-CVS151-0081 | The server shall allow request that are contained in role 0 rule regardless of the value of Confidentiality field setting. | CVS151.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS151 > Page 19 / page 19 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_INFO 40 RFQX: RFQX-CVS151-0082 | This means that in role 0 encryption is never required. | CVS151.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS151 > Page 19 / page 19 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| RBAC_REQ 28 RFQX: RFQX-CVS151-0083 | The server shall always allow reception of UDS authenticate 0x29 requests regardless of the RBACC settings. | CVS151.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 3.14 Requests Specific Requirements 3.14.1 Diagnostic over USD 3.14.1.1 Authenticate 0x29 / page 19 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_INFO 42 RFQX: RFQX-CVS151-0084 | For 0x29 requests a corresponding matching rule in the RBACC is not required for the server to accept the request. | CVS151.pdf | IT / backend | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS151 > Page 19 / page 19 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| RBAC_REQ 29 RFQX: RFQX-CVS151-0085 | The server shall evaluate the reported internal service using the RBACC rules whenever it receives a UDS Service 0x84 requests. | CVS151.pdf | Software | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3.14.1.2 SecuredData Transmission 0x84 / page 19 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_REQ 30 RFQX: RFQX-CVS151-0086 | The server shall always allow reception of UDS SecuredDataTransmission 0x84 requests regardless of the RBACC settings. | CVS151.pdf | IT / backend | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS151 > Page 19 / page 19 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_INFO 43 RFQX: RFQX-CVS151-0087 | 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. | CVS151.pdf | IT / backend | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS151 > Page 19 / page 19 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| RBAC_REQ 31 RFQX: RFQX-CVS151-0088 | The server shall always allow reception of UDS TesterPresent 0x3E requests regardless of the RBACC settings. | CVS151.pdf | IT / backend | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 3.14.1.3 TesterPresent 0x3E / page 20 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RBAC_INFO 44 RFQX: RFQX-CVS151-0089 | For 0x3E requests a corresponding matching rule in the RBACC is not required for the server to accept the request. | CVS151.pdf | IT / backend | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS151 > Page 20 / page 20 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| RBAC_INFO 45 RFQX: RFQX-CVS151-0090 | Refreshing the S3 timer (see CVS124), e.g., using TesterPresent (0x3E) (see CVS37), is always possible to do outside the secure channel and regardless of the settings in the RBACC role configuration. | CVS151.pdf | Cybersecurity | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS151 > Page 20 / page 20 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS151-0091 RFQX: RFQX-CVS151-0091 | 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). | CVS151.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS151 > Page 26 / page 26 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| RFQX-CVS151-0092 RFQX: RFQX-CVS151-0092 | The client must have read access for all included DIDs and have access to the service themselves. | CVS151.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS151 > Page 26 / page 26 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS151-0093 RFQX: RFQX-CVS151-0093 | 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. | CVS151.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS151 > Page 26 / page 26 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS151-0094 RFQX: RFQX-CVS151-0094 | 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. | CVS151.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS151 > Page 26 / page 26 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS154-0001 RFQX: RFQX-CVS154-0001 | 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. | CVS154.pdf | Cybersecurity | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS154 > Page 1 / page 1 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No supplier action - document reference / boilerplate. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS154-0002 RFQX: RFQX-CVS154-0002 | 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”. | CVS154.pdf | Process / compliance | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS154 > Page 1 / page 1 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS154-0003 RFQX: RFQX-CVS154-0003 | The User shall apply the latest version of this CVS154. | CVS154.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS154 > Page 1 / page 1 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS154-0004 RFQX: RFQX-CVS154-0004 | This document shall be used accompanied with these specifications. | CVS154.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS154 > Page 3 / page 3 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| DSC_BASE_INFO 1 RFQX: RFQX-CVS154-0005 | See further chapter 3.2 DSC ASN.1 definition for element types. | CVS154.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 3 Technical content 3.1 DSC structure / page 4 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| DSC_BASE_INFO 2 RFQX: RFQX-CVS154-0006 | The DSC is divided in a metadata header block and three configuration blocks as shown in Figure 2 verificationEntries[..] encryptionEntries[..] itemEntries[..] id version Metadata Figure 2 – DSC structure | CVS154.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS154 > Page 4 / page 4 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| DSC_BASE_INFO 3 RFQX: RFQX-CVS154-0007 | • version: specifies a version of the DSC structure, namely the DSC ASN.1 definition and its elements within the DSC instance. | CVS154.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS154 > Page 5 / page 5 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| DSC_BASE_REQ 37 RFQX: RFQX-CVS154-0008 | The server shall support a DSC Metadata block containing version and id fields. | CVS154.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS154 > Page 5 / page 5 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| DSC_BASE_REQ 43 RFQX: RFQX-CVS154-0009 | The server shall support the Major and Minor version as specified in 3.2. | CVS154.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS154 > Page 5 / page 5 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| DSC_BASE_REQ 29 RFQX: RFQX-CVS154-0010 | The server shall support a DSC containing verificationEntries. | CVS154.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS154 > Page 5 / page 5 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| DSC_BASE_REQ 30 RFQX: RFQX-CVS154-0011 | The server shall support a DSC containing encryptionEntries. | CVS154.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS154 > Page 5 / page 5 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| DSC_BASE_REQ 31 RFQX: RFQX-CVS154-0012 | The server shall support a DSC containing itemEntries. | CVS154.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS154 > Page 5 / page 5 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| DSC_BASE_REQ 45 RFQX: RFQX-CVS154-0013 | 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. | CVS154.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS154 > Page 5 / page 5 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| DSC_BASE_REQ 46 RFQX: RFQX-CVS154-0014 | 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. | CVS154.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS154 > Page 5 / page 5 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| DSC_BASE_REQ 49 RFQX: RFQX-CVS154-0015 | 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. | CVS154.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS154 > Page 5 / page 5 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| DSC_BASE_REQ 26 RFQX: RFQX-CVS154-0016 | The server shall support an empty DSC containing only Metadata (version and id) and the empty sequences for verificationEntries, encryptionEntries and ItemEntries. | CVS154.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS154 > Page 5 / page 5 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| DSC_BASE_INFO 44 RFQX: RFQX-CVS154-0017 | An empty DSC issued by client means that in addition to Metadata, the syntax must be correct in accordance with Annex B. | CVS154.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS154 > Page 5 / page 5 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| DSC_BASE_INFO 33 RFQX: RFQX-CVS154-0018 | 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. | CVS154.pdf | IT / backend | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS154 > Page 6 / page 6 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| DSC_BASE_INFO 4 RFQX: RFQX-CVS154-0019 | The VerificationEntry is of ASN.1 type CHOICE, where the choice stipulates the verification strategy for a piece of data. | CVS154.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page 3.1.1 VerificationEntry / page 6 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| DSC_BASE_INFO 38 RFQX: RFQX-CVS154-0020 | See 3.2 for the context-specific tag number for the VerificationEntry choices. | CVS154.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS154 > Page 6 / page 6 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| DSC_BASE_REQ 5 RFQX: RFQX-CVS154-0021 | VerificationEntry hashCmp states that a hash comparison shall be used to verify the data. | CVS154.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 3.1.1.1 HashCmp / page 6 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| DSC_BASE_INFO 6 RFQX: RFQX-CVS154-0022 | When the server is instructed to verify the programmed data, in general the following actions are taken by the server. | CVS154.pdf | IT / backend | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS154 > Page 6 / page 6 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS154-0023 RFQX: RFQX-CVS154-0023 | However, the instance specification may state specialized actions: • Server processes each VerificationEntry one by one. | CVS154.pdf | IT / backend | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS154 > Page 6 / page 6 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| DSC_BASE_INFO 7 RFQX: RFQX-CVS154-0024 | Definition of hashCmp fields: Refer to Figure 3 for type definitions of each field. | CVS154.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS154 > Page 6 / page 6 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS154-0025 RFQX: RFQX-CVS154-0025 | • hashAlgorithm: States which HashAlgorithm (see RFC 6234) shall be used for hashing the data to verify. | CVS154.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS154 > Page 7 / page 7 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS154-0026 RFQX: RFQX-CVS154-0026 | • dataRanges: sequence of Range items - Range: Information on which data chunks that shall be verified. | CVS154.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS154 > Page 7 / page 7 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| DSC_BASE_REQ 47 RFQX: RFQX-CVS154-0027 | The server shall support the SHA512 HashAlgorithm as referred in 3.2 ASN1 definition. | CVS154.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS154 > Page 7 / page 7 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| DSC_BASE_INFO 9 RFQX: RFQX-CVS154-0028 | The encryptionEntry is of ASN.1 type CHOICE stipulating the decryption strategy for a piece of data. | CVS154.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page 3.1.2 EncryptionEntry / page 7 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| DSC_BASE_REQ 39 RFQX: RFQX-CVS154-0029 | For crypto agility reasons, both of the choices shall be supported by the server. | CVS154.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS154 > Page 7 / page 7 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| DSC_BASE_INFO 40 RFQX: RFQX-CVS154-0030 | See 3.2 for the context-specific tag number for the EncryptionEntry choices. | CVS154.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS154 > Page 7 / page 7 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| DSC_BASE_REQ 11 RFQX: RFQX-CVS154-0031 | The initial counter value shall be set to 0 (zero). | CVS154.pdf | System | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS154 > Page 7 / page 7 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS154-0032 RFQX: RFQX-CVS154-0032 | Range: Information on which data chunks that shall be decrypted. | CVS154.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS154 > Page 8 / page 8 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| DSC_BASE_INFO 17 RFQX: RFQX-CVS154-0033 | An ItemEntry is of ASN.1 type CHOICE, where the choice stipulates the type of item the ItemEntry holds. | CVS154.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 3.1.3 ItemEntry / page 9 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| DSC_BASE_REQ 41 RFQX: RFQX-CVS154-0034 | The structure version for this document release shall be: Major ‘04’ and Minor ‘00’ | CVS154.pdf | System | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS154 > Page 9 / page 9 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| DSC_BASE_REQ 42 RFQX: RFQX-CVS154-0035 | 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 } | CVS154.pdf | IT / backend | Low extraction confidence or flagged for human review. Linked source table/diagram context was considered for interpretation. | Needs internal review. Confirm the extracted wording and the intended scope before committing a supplier position. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Re-read the Source document, confirm intent, then re-issue an Accept/Partial position. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | NEEDS REVIEW | Analysis detailsSource section/page CVS154 > Page 9 / page 9 Pre-analysis Low extraction confidence or flagged for human review. Linked source table/diagram context was considered for interpretation. Assumptions Internal review confirms wording and scope. Engineering notes Complete internal review of wording and baseline scope. Risk / impact Limited; standard implementation and verification risk. |
| DSC_BASE_REQ 19 RFQX: RFQX-CVS154-0036 | 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. | CVS154.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS154 > Page 10 / page 10 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| DSC_BASE_REQ 51 RFQX: RFQX-CVS154-0037 | The length of the version field shall be verified. | CVS154.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS154 > Page 10 / page 10 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| REQ_DSC_BASE_20 RFQX: RFQX-CVS154-0038 | The version shall be verified with the servers supported Major and Minor version of the DSC logic for compliancy. | CVS154.pdf | Software | Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS154 > Page 10 / page 10 Pre-analysis Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| DSC_BASE_REQ 34 RFQX: RFQX-CVS154-0039 | The length of the id field shall be verified. | CVS154.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS154 > Page 10 / page 10 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| DSC_BASE_REQ 27 RFQX: RFQX-CVS154-0040 | The hashAlgorithm shall be supported by the server. | CVS154.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS154 > Page 10 / page 10 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| DSC_BASE_REQ 50 RFQX: RFQX-CVS154-0041 | The length of every referenceHash shall be consistent with the output size of the hash algorithm specified in the hashAlgorithm. | CVS154.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS154 > Page 11 / page 11 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| DSC_BASE_INFO 35 RFQX: RFQX-CVS154-0042 | The verification of servers support of specified dataRanges in the VerificationEntry, shall be stated for the DSC instance. | CVS154.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS154 > Page 11 / page 11 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| DSC_BASE_REQ 28 RFQX: RFQX-CVS154-0043 | The EncryptionEntry algorithm shall be supported by the server. | CVS154.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS154 > Page 11 / page 11 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| DSC_BASE_REQ 22 RFQX: RFQX-CVS154-0044 | The length of key and iv shall be verified accordingly to the algorithm stipulated in EncryptionEntry. | CVS154.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS154 > Page 11 / page 11 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| DSC_BASE_INFO 36 RFQX: RFQX-CVS154-0045 | The verification of servers support of specified dataRanges in the EncryptionEntry, shall be stated for the DSC instance. | CVS154.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS154 > Page 11 / page 11 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| DSC_BASE_REQ 48 RFQX: RFQX-CVS154-0046 | 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. | CVS154.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS154 > Page 11 / page 11 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS154-0047 RFQX: RFQX-CVS154-0047 | The sequence tags for verificationEntries, encryptionEntries and itemEntries are required but empty (zero length). | CVS154.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS154 > Page 14 / page 14 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS31-0001 RFQX: RFQX-CVS31-0001 | The User shall apply the latest version of this CVS31. | CVS31.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS31 > Page 1 / page 1 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS31-0002 RFQX: RFQX-CVS31-0002 | Foreword This CVS31 contains requirement specification for TRATON GROUP and may be used by all within TRATON Group, if applicable. | CVS31.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 3 / page 3 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No supplier action - document reference / boilerplate. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS31-0003 RFQX: RFQX-CVS31-0003 | 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”. | CVS31.pdf | Process / compliance | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS31 > Page 3 / page 3 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS31-0004 RFQX: RFQX-CVS31-0004 | The whole standard has been reworked and shall be read in its entirety. | CVS31.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS31 > Page 3 / page 3 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS31-0005 RFQX: RFQX-CVS31-0005 | • 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. | CVS31.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS31 > Page 3 / page 3 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| 1.1 RFQX: RFQX-CVS31-0006 | The purpose of this document is to clarify vehicle manufacture specific extensions and exceptions to the Authentication 0x29 service specified in ISO 14229-1:2020. CVS150 Cryptographic Specification CVS32 SecuredDataTransmis sion 0x84 CVS151 RBAC CVS33 Entity Management Protocol (EMP) CVS31 Authenticate 0x29 CVS124 Traton Specification on Unified diagnostic services (UDS) CVS30 X.509 Specification CVS34 EMP – Basic Entities Figure 1 – Overview of relation between specifications The following documents are normative and indispensable for the application of this document: • Traton Specification on Unified diagnostic Services (UDS) requirements (CVS124) • ISO 14229-1:2020, Road vehicles — Unified diagnostic services (UDS) — Part 1: Specification and requirements Whenever a requirement in this specification or the Traton Specification on Unified diagnostic Services (UDS) requirements (CVS124) is non-compliant with one or more requirements in ISO 14229-1:2020 the requirements in this specification and (CVS124) take precedence. Any deviations from this specification shall be documented and must be reviewed by the vehicle manufacturer. It is the vehicle manufacturer that decides if a deviation can be accepted or not. Multiple security concepts are available in the Authentication (ISO 14229-1:2020) service, however, only APCE (ISO 14229-1:2020) is supported by the concept described in this document, see Figure 2. | CVS31.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 4 / page 4 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| RFQX-CVS31-0007 RFQX: RFQX-CVS31-0007 | Any deviations from this specification shall be documented and must be reviewed by the vehicle manufacturer. | CVS31.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS31 > Page 4 / page 4 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS31-0008 RFQX: RFQX-CVS31-0008 | Shall be agreed between the supplier and the vehicle manufacturer. | CVS31.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS31 > Page 6 / page 6 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS31-0009 RFQX: RFQX-CVS31-0009 | It contains the information required for the server to verify the client’s subsequent request and to generate the corresponding response. | CVS31.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS31 > Page 6 / page 6 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RFQX-CVS31-0010 RFQX: RFQX-CVS31-0010 | It contains the information required for the server to maintain continuous authenticated communication with the client and to generate authenticated responses. | CVS31.pdf | IT / backend | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS31 > Page 6 / page 6 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_INFO 1 RFQX: RFQX-CVS31-0011 | This section of the document describes vehicle manufacturer specific requirements regarding the behaviour and content of the subFunctions (ISO 14229-1:2020) found in Table 4. | CVS31.pdf | Process / compliance | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS31 > Page 7 / page 7 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 1 RFQX: RFQX-CVS31-0012 | The server shall only support subfunctions in Table 4. | CVS31.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS31 > Page 7 / page 7 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_INFO 2 RFQX: RFQX-CVS31-0013 | In this document, each subFunction (ISO 14229-1:2020) is described in its own sub-section. | CVS31.pdf | Process / compliance | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS31 > Page 7 / page 7 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 155 RFQX: RFQX-CVS31-0014 | The server shall not accept an application-layer service 0x29 request when it is received inside an SDT (service 0x84) protected message. | CVS31.pdf | Software | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page Table 4 – Supported subFunctions (ISO 14229-1:2020) Name verifyCertificateBidirectional proofOfOwnership deAuthenticate / page 7 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RFQX-CVS31-0015 RFQX: RFQX-CVS31-0015 | If such an encapsulated 0x29 request is detected, the server shall return application-layer NRC 0x39, provided as a correctly formatted SDT positive response. | CVS31.pdf | Software | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS31 > Page 7 / page 7 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 2 RFQX: RFQX-CVS31-0016 | The request for verifyCertificateBidirectional subfunction shall be formatted according to | CVS31.pdf | System | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 8 / page 8 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_REQ 117 RFQX: RFQX-CVS31-0017 | 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 Upon reception of a verifyCertificateBidirectional request, the server shall determine whether the Authentication delay timer is currently running. | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 8 / page 8 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_INFO 30 RFQX: RFQX-CVS31-0018 | For details on Authentication delay timer, refer to chapter 4.8. | CVS31.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS31 > Page 8 / page 8 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 118 RFQX: RFQX-CVS31-0019 | If upon reception of verifyCertificateBidirectional request the Authentication delay timer is expired, the server shall continue to process the verifyCertificateBidirectional request. | CVS31.pdf | IT / backend | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 8 / page 8 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_INFO 24 RFQX: RFQX-CVS31-0020 | 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. | CVS31.pdf | IT / backend | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS31 > Page 8 / page 8 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_REQ 45 RFQX: RFQX-CVS31-0021 | If the server verifies the client certificate as valid, the server shall create the requested client authentication pending state. | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 8 / page 8 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 119 RFQX: RFQX-CVS31-0022 | If an authentication pending state already exists, the server shall replace the existing | CVS31.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 9 / page 9 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_INFO 27 RFQX: RFQX-CVS31-0023 | For details in how to validate a client certificate, refer to chapter 4.1. | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS31 > Page 9 / page 9 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 3 RFQX: RFQX-CVS31-0024 | This field shall consists of 32 octets. | CVS31.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 3.1.1.1 challengeClient / page 9 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_REQ 4 RFQX: RFQX-CVS31-0025 | The challengeClient (ISO 14229-1:2020) shall be generated using a CRNG. | CVS31.pdf | Process / compliance | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 9 / page 9 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_REQ 172 RFQX: RFQX-CVS31-0026 | The expected range values of lengthOfCertificateClient shall be from 0x00C8 to 0x0800. | CVS31.pdf | System | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 3.1.1.2 lengthOfCertificateClient / page 9 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_REQ 173 RFQX: RFQX-CVS31-0027 | The server shall verify the value of lengthOfCertificateClient upon reception of verifyCertificateBidirectional request. | CVS31.pdf | IT / backend | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 9 / page 9 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 174 RFQX: RFQX-CVS31-0028 | If the lengthOfCertificateClient value is not within the expected range, the server shall send negative response code 0x13 (incorrectMessageLengthOrInvalidFormat). | CVS31.pdf | IT / backend | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 9 / page 9 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 5 RFQX: RFQX-CVS31-0029 | The response for verifyCertificateBidirectional subfunction shall be formatted according to Table 6. | CVS31.pdf | System | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 3.1.2 Response / page 9 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_REQ 120 RFQX: RFQX-CVS31-0030 | Upon positively responding, the server shall start the Authentication completion timer. | CVS31.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 9 / page 9 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 6 RFQX: RFQX-CVS31-0031 | The challengeServer field shall consists of 32 octets generated using a CRNG. | CVS31.pdf | System | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page ephemeralPublicKeyServer See 3.1.2.3 uint8[] M Yes 3.1.2.1 challengeServer / page 10 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_INFO 143 RFQX: RFQX-CVS31-0032 | This field consists of a signature that proves to the client that the server has access to the private key of the provided certificateServer (ISO 14229-1:2020). Additionally, the field proves that the same message sent by the client has been received by the server and vice-versa. | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS31 > Page 11 / page 11 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 7 RFQX: RFQX-CVS31-0033 | The proof/signature shall be generated according to the pseudo code below. | CVS31.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS31 > Page 11 / page 11 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_INFO 60 RFQX: RFQX-CVS31-0034 | For obvious reasons, the proofOfOwnershipServer in the VerifyCertificates is not included, in the “concatenation” (see pseudo code above) when the signature/proof is being calculated. | CVS31.pdf | System | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page 𝐻0 ∶= 𝑆𝐻𝐴512_ℎ𝑎𝑠ℎ(𝑉𝑒𝑟𝑖𝑓𝑦𝐶𝑒𝑟𝑡𝑖𝑓𝑖𝑐𝑎𝑡𝑒𝑟𝑒𝑞|| 𝑉𝑒𝑟𝑖𝑓𝑦𝐶𝑒𝑟𝑡𝑖𝑓𝑖𝑐𝑎𝑡𝑒𝑟𝑒𝑠) 𝑃𝑟𝑜𝑜𝑓𝑂𝑓𝑂𝑤𝑛𝑒𝑟𝑠ℎ𝑖𝑝𝑆𝑒𝑟𝑣𝑒𝑟 ∶= 𝑆𝑖𝑔𝑛(𝑆𝑒𝑟𝑣𝑒𝑟𝑃𝑟𝑖𝑣𝑎𝑡𝑒𝐾𝑒𝑦, 𝐻0) / page 11 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 4 RFQX: RFQX-CVS31-0035 | This field provides the client with the necessary server-side data for the chosen key-exchange scheme/algorithm. | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page 3.1.2.3 ephemeralPublicKeyServer / page 11 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 121 RFQX: RFQX-CVS31-0036 | 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. | CVS31.pdf | IT / backend | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 3.1.3 Negative Response / page 11 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 122 RFQX: RFQX-CVS31-0037 | 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. | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 11 / page 11 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 123 RFQX: RFQX-CVS31-0038 | 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. | CVS31.pdf | IT / backend | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 11 / page 11 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_INFO 5 RFQX: RFQX-CVS31-0039 | This subfunction (ISO 14229-1:2020) serves several purposes – it proves to the server that the client owns the private key of the provided certificateClient (ISO 14229-1:2020). | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page 3.2 proofOfOwnership / page 11 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 8 RFQX: RFQX-CVS31-0040 | The request for proofOfOwnership subfunction shall be defined according to Table 7. | CVS31.pdf | System | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS31 > Page 12 / page 12 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_REQ 116 RFQX: RFQX-CVS31-0041 | If the client’s proofOfOwnership signature is successfully verified, the server shall establish a new authentication state for the client. | CVS31.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 12 / page 12 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 110 RFQX: RFQX-CVS31-0042 | 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 The server shall verify whether any existing authentication pending state corresponds to the client submitting the proofOfOwnership request. | CVS31.pdf | Software | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 12 / page 12 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 111 RFQX: RFQX-CVS31-0043 | If an existing authentication pending state is found, the server shall verify if the Authentication completion timer is currently running. | CVS31.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 12 / page 12 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_INFO 31 RFQX: RFQX-CVS31-0044 | For details on Authentication completion timer, refer to chapter 4.9. | CVS31.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS31 > Page 12 / page 12 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 112 RFQX: RFQX-CVS31-0045 | If the Authentication completion timer is currently running, the server shall continue to process the client’s proofOfOwnership request. | CVS31.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 12 / page 12 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 113 RFQX: RFQX-CVS31-0046 | If the client proofOfOwnership signature verification fails, the server shall delete the authentication pending state connected to the client submitting the proofOfOwnership request. | CVS31.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 12 / page 12 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 114 RFQX: RFQX-CVS31-0047 | 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. | CVS31.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 12 / page 12 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 115 RFQX: RFQX-CVS31-0048 | If the client’s proofOfOwnership signature is successfully verified, the server shall establish a new authentication state for the client. | CVS31.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 12 / page 12 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RFQX-CVS31-0049 RFQX: RFQX-CVS31-0049 | If an active authentication state already exists, the server shall replace the existing state with the newly established one. | CVS31.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS31 > Page 13 / page 13 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_INFO 141 RFQX: RFQX-CVS31-0050 | The field proofOfOwnershipClient is a signature that proves to the server that the client has access to the private key of the certificateClient (ISO 14229-1:2020). | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page 3.2.1.1 proofOfOwnershipClient / page 13 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 160 RFQX: RFQX-CVS31-0051 | The proofOfOwnershipClient shall be generated according to the pseudo code below. | CVS31.pdf | System | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS31 > Page 13 / page 13 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_INFO 142 RFQX: RFQX-CVS31-0052 | The reason for the concatenation, is to ensure that the full communication (all sent and received requests and responses) has integrity. | CVS31.pdf | System | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS31 > Page 13 / page 13 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 3 RFQX: RFQX-CVS31-0053 | This field provides the server with the necessary client-side data for the chosen key-exchange scheme/algorithm. | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 3.2.1.2 ephemeralPublicKeyClient / page 13 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 161 RFQX: RFQX-CVS31-0054 | The response for proofOfOwnership subfunction shall be according to Table 8. | CVS31.pdf | System | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 3.2.2 Response / page 13 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_INFO 140 RFQX: RFQX-CVS31-0055 | The sessionKeyInfo includes a signature that proves to the client that the server has accepted the proofOfOwnership (ISO 14229-1:2020). | CVS31.pdf | IT / backend | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS31 > Page 14 / page 14 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 162 RFQX: RFQX-CVS31-0056 | The signature shall be generated according to the pseudo code below. | CVS31.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS31 > Page 14 / page 14 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_INFO 145 RFQX: RFQX-CVS31-0057 | For obvious reasons, the sessionKeyInfo in the ProofOfOwnershipres is not included, in the “concatenation” (see pseudo code above) when the signature is being calculated. | CVS31.pdf | System | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS31 > Page 14 / page 14 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 124 RFQX: RFQX-CVS31-0058 | 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. | CVS31.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 3.2.3 Negative Response / page 14 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 125 RFQX: RFQX-CVS31-0059 | 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. | CVS31.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 14 / page 14 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 126 RFQX: RFQX-CVS31-0060 | 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. | CVS31.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 14 / page 14 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 127 RFQX: RFQX-CVS31-0061 | 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. | CVS31.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 14 / page 14 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 128 RFQX: RFQX-CVS31-0062 | 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. | CVS31.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 14 / page 14 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 129 RFQX: RFQX-CVS31-0063 | 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. | CVS31.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 14 / page 14 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_INFO 11 RFQX: RFQX-CVS31-0064 | This chapter specifies the behaviour of the deAuthenticate subfunction. | CVS31.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS31 > Page 15 / page 15 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 159 RFQX: RFQX-CVS31-0065 | The request for deAuthenticate subfunction shall be formatted according to Table 9. | CVS31.pdf | System | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 3.3.1 Request / page 15 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_REQ 96 RFQX: RFQX-CVS31-0066 | 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 The response for deAuthenticate subfunction shall be formatted according to Table 10. | CVS31.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 15 / page 15 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_REQ 158 RFQX: RFQX-CVS31-0067 | The server shall delete/invalidate the client’s authentication prior to positively responding to the deAuthenticate request. | CVS31.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 0x00 – 0xFF M / page 15 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 130 RFQX: RFQX-CVS31-0068 | 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. | CVS31.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 3.3.3 Negative Response / page 15 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_INFO 32 RFQX: RFQX-CVS31-0069 | The server only responds NRC 0x24 in the case that it can confirm that there is no authentication state connected to the client requesting to deAuthenticate. | CVS31.pdf | IT / backend | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS31 > Page 15 / page 15 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 131 RFQX: RFQX-CVS31-0070 | 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. | CVS31.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS31 > Page 15 / page 15 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 132 RFQX: RFQX-CVS31-0071 | 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, | CVS31.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 16 / page 16 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_INFO 133 RFQX: RFQX-CVS31-0072 | 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. | CVS31.pdf | IT / backend | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS31 > Page 16 / page 16 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 175 RFQX: RFQX-CVS31-0073 | The signature algorithm used throughout the authentication process shall be ED25519. | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 4 General 4.1 Certificate / page 16 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| AUTH_REQ 176 RFQX: RFQX-CVS31-0074 | The client shall use the private key corresponding to the client certificate to generate the signatures. | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 16 / page 16 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| AUTH_REQ 177 RFQX: RFQX-CVS31-0075 | The server shall use the private key corresponding to the server certificate to generate the signatures. | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 16 / page 16 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_INFO 101 RFQX: RFQX-CVS31-0076 | The signature algorithm in the client, server and authentication CA certificates are ED25519 (1.3.101.112). | CVS31.pdf | IT / backend | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS31 > Page 16 / page 16 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 163 RFQX: RFQX-CVS31-0077 | The format and the structure of the certificates shall be based on (CVS30). | CVS31.pdf | System | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 16 / page 16 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_REQ 164 RFQX: RFQX-CVS31-0078 | The server shall reject a received client’s certificate, sent using the verifyCertificateBidirectional subFunction, if it matches the server’s own certificate. | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 16 / page 16 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_INFO 7 RFQX: RFQX-CVS31-0079 | It should not be possible to “unlock” the server using its own key/certificate. | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS31 > Page 16 / page 16 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| AUTH_REQ 165 RFQX: RFQX-CVS31-0080 | The server shall verify the client certificate, sent using the verifyCertificateBidirectional subFunction, according to Figure 3. | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 16 / page 16 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 134 RFQX: RFQX-CVS31-0081 | The server shall verify the Signature of the Client certificate using the AUTH-CA EMP entity public key. | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 16 / page 16 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 166 RFQX: RFQX-CVS31-0082 | • Check if the NodeUID of the server is present in the NodeUIDs extension. | CVS31.pdf | IT / backend | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS31 > Page 18 / page 18 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 9 RFQX: RFQX-CVS31-0083 | • If the server NodeUID is not found in the NodeUID extension, the server shall reject the certificate and generate NRC 0x10 (generalReject). | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 18 / page 18 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 106 RFQX: RFQX-CVS31-0084 | If the NodeUID extension is not detected, the operation shall continue as in | CVS31.pdf | System | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS31 > Page 18 / page 18 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_INFO 25 RFQX: RFQX-CVS31-0085 | A certificate without NodeUID extension implies that the certificate is applicable for any NodeUID. | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS31 > Page 18 / page 18 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 100 RFQX: RFQX-CVS31-0086 | The maximum number of elements in the list (number of ids) is limited by the maximum size of the certificate. | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS31 > Page 18 / page 18 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 11 RFQX: RFQX-CVS31-0087 | For the length of NodeUID see (CVS124). | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 18 / page 18 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 170 RFQX: RFQX-CVS31-0088 | The ECU-Diagnostic role extension shall be included in the client certificate. | CVS31.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 4.1.2 ECU-Diagnostic Role extension / page 18 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| AUTH_REQ 13 RFQX: RFQX-CVS31-0089 | The roles shall correspond to a bit pattern-octet string. | CVS31.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 18 / page 18 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_INFO 8 RFQX: RFQX-CVS31-0090 | 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. | CVS31.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS31 > Page 18 / page 18 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_INFO 9 RFQX: RFQX-CVS31-0091 | The D-RBACC extension defines client-specific rules that override the role-based access control configuration in the server. | CVS31.pdf | IT / backend | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page 4.1.3 D-RBACC extension / page 18 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS31-0092 RFQX: RFQX-CVS31-0092 | 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. | CVS31.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 18 / page 18 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 14 RFQX: RFQX-CVS31-0093 | If D-RBACC extension is detected, the server shall overrule the RBACC with the D-RBACC permissions. | CVS31.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS31 > Page 18 / page 18 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_INFO 61 RFQX: RFQX-CVS31-0094 | 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. | CVS31.pdf | Software | Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS31 > Page 18 / page 18 Pre-analysis Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_REQ 135 RFQX: RFQX-CVS31-0095 | • The server shall validate the D-RBACC by parsing all its content. If content is invalid, | CVS31.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS31 > Page 19 / page 19 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RFQX-CVS31-0096 RFQX: RFQX-CVS31-0096 | If content is invalid, the certificate is invalid and the server shall return a Negative Response Code (NRC) 0x10, indicating generalReject. | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS31 > Page 19 / page 19 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_INFO 33 RFQX: RFQX-CVS31-0097 | • Parsing means that the server tries to decode the DER encoded D-RBACC structure, which includes checking the decoded results against the server’s supported/known ASN.1 definition. | CVS31.pdf | IT / backend | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS31 > Page 19 / page 19 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 136 RFQX: RFQX-CVS31-0098 | • The server shall verify that the D-RBACC version provided by the client is compatible with the server’s supported D-RBACC version. | CVS31.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS31 > Page 19 / page 19 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RFQX-CVS31-0099 RFQX: RFQX-CVS31-0099 | If non-compliant, the certificate is invalid and the server shall return a Negative Response Code (NRC) 0x10, indicating generalReject. | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS31 > Page 19 / page 19 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 42 RFQX: RFQX-CVS31-0100 | The basicConstraints extension CA field shall be False. | CVS31.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 4.1.4 basicContraints extension / page 19 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_REQ 15 RFQX: RFQX-CVS31-0101 | The Key Usage extension (RFC 5280) shall be included in the client certificate. | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 4.1.5 Key Usage extension / page 19 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| AUTH_REQ 47 RFQX: RFQX-CVS31-0102 | The Key Usage extension shall contain DigitalSignature. | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 19 / page 19 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| AUTH_REQ 95 RFQX: RFQX-CVS31-0103 | The Extended Key Usage extension (RFC 5280) shall be included in the client certificate. | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 4.1.6 Extended Key Usage extension / page 19 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| AUTH_REQ 107 RFQX: RFQX-CVS31-0104 | The extension ExtendedKeyUsage shall contain clientAuth (1.3.6.1.5.5.7.3.2). | CVS31.pdf | System | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 19 / page 19 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_REQ 105 RFQX: RFQX-CVS31-0105 | The extension SignatureAlgorithm shall contain ED25519 (1.3.101.112). | CVS31.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 4.1.7 SignatureAlgorithm / page 19 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_REQ 169 RFQX: RFQX-CVS31-0106 | The server shall validate the certificate so that: 𝑛𝑜𝑡𝐵𝑒𝑓𝑜𝑟𝑒 ≤ 𝐶𝑒𝑟𝑡𝑖𝑓𝑖𝑐𝑎𝑡𝑒-𝑡𝑖𝑚𝑒 ≤ 𝑛𝑜𝑡𝐴𝑓𝑡𝑒𝑟 | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 19 / page 19 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_INFO 137 RFQX: RFQX-CVS31-0107 | The notBefore and notAfter are received as fields in the certificate while Certificate-Time is the EMP entity defined in CVS34. | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS31 > Page 19 / page 19 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 138 RFQX: RFQX-CVS31-0108 | • The server is reset (i.e server is power cycled). | CVS31.pdf | IT / backend | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS31 > Page 20 / page 20 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 143 RFQX: RFQX-CVS31-0109 | State-keeping | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 4.2 State-keeping / page 20 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 139 RFQX: RFQX-CVS31-0110 | • Power failure. | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 20 / page 20 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 156 RFQX: RFQX-CVS31-0111 | 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. | CVS31.pdf | Software | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 20 / page 20 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_INFO 134 RFQX: RFQX-CVS31-0112 | If a request to reset (e.g service 0x11) is received over the service 0x84 (securedDataTransmission) it permits the server to respond before the sessionKey is locked/invalidated. | CVS31.pdf | Software | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS31 > Page 20 / page 20 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 16 RFQX: RFQX-CVS31-0113 | If a client and server have successfully completed the authentication process, the server shall invalidate the authentication state in the event of: • The server is reset (i.e server is power cycled). | CVS31.pdf | IT / backend | Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 20 / page 20 Pre-analysis Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 17 RFQX: RFQX-CVS31-0114 | • Power failure. | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 20 / page 20 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 18 RFQX: RFQX-CVS31-0115 | • Successful deAuthenticate (see 3.3) subFunction (ISO 14229-1:2020). | CVS31.pdf | Process / compliance | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 20 / page 20 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 19 RFQX: RFQX-CVS31-0116 | • A new successful authentication is established. | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | High | Analysis detailsSource section/page CVS31 > Page 20 / page 20 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 20 RFQX: RFQX-CVS31-0117 | • By passive de-authentication, see 4.7. | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | High | Analysis detailsSource section/page CVS31 > Page 20 / page 20 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 10 RFQX: RFQX-CVS31-0118 | Authentication state invalidated by the server implies that any unlocked services and sessionKey is locked/invalidated. | CVS31.pdf | IT / backend | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS31 > Page 20 / page 20 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 157 RFQX: RFQX-CVS31-0119 | 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. | CVS31.pdf | Software | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 20 / page 20 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 140 RFQX: RFQX-CVS31-0120 | The server’s authentication pending state shall contain the minimum of (non-exhaustive list): • Client address that issued the authentication request. | CVS31.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 20 / page 20 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 141 RFQX: RFQX-CVS31-0121 | • Authentication completion timer. | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | High | Analysis detailsSource section/page CVS31 > Page 20 / page 20 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 142 RFQX: RFQX-CVS31-0122 | • Client’s certificate public key | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 20 / page 20 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 144 RFQX: RFQX-CVS31-0123 | • Client D-RBACC, if provided in the client’s certificate | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 21 / page 21 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 145 RFQX: RFQX-CVS31-0124 | • Server ephemeral private key | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 21 / page 21 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 146 RFQX: RFQX-CVS31-0125 | • H0 hash value | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 21 / page 21 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 34 RFQX: RFQX-CVS31-0126 | The server ephemeral private key is the pair of the public key (ephemeralPublicKeyServer) sent as verifyCertificateBidirectional response. | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS31 > Page 21 / page 21 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 35 RFQX: RFQX-CVS31-0127 | H0 hash value is calculated as part of proofOfOwnershipServer in verifyCertificateBidirectional response. | CVS31.pdf | System | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS31 > Page 21 / page 21 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 21 RFQX: RFQX-CVS31-0128 | The server’s authentication state shall contain the minimum of (non-exhaustive list): • SessionKey. | CVS31.pdf | IT / backend | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 21 / page 21 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 22 RFQX: RFQX-CVS31-0129 | • A3 Timer for passive de-authentication information. | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | High | Analysis detailsSource section/page CVS31 > Page 21 / page 21 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 23 RFQX: RFQX-CVS31-0130 | • Client address that issued the authentication request. | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | High | Analysis detailsSource section/page CVS31 > Page 21 / page 21 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 147 RFQX: RFQX-CVS31-0131 | • Client roles (ECU diagnostic Role extension in client’s certificate) | CVS31.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 21 / page 21 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 148 RFQX: RFQX-CVS31-0132 | • Client D-RBACC, if provided in the client’s certificate | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 21 / page 21 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 149 RFQX: RFQX-CVS31-0133 | The server shall support only one authentication state. | CVS31.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 21 / page 21 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 150 RFQX: RFQX-CVS31-0134 | The server shall support only one authentication pending state. | CVS31.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 21 / page 21 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_INFO 135 RFQX: RFQX-CVS31-0135 | The ephemeralPublicKeyClient in the proofOfOwnership-request (from the client) and the ephemeralPublicKeyClient in the verifyCertificate-response (from the server) consists of a Curve25519 [RFC 7748] public key. | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS31 > Page 22 / page 22 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 136 RFQX: RFQX-CVS31-0136 | An overview of the key-exchange process is shown in Figure 4. | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS31 > Page 22 / page 22 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 167 RFQX: RFQX-CVS31-0137 | The private keys shall be generated using a CRNG. | CVS31.pdf | System | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 22 / page 22 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_REQ 168 RFQX: RFQX-CVS31-0138 | The sessionKey shall be generated according to the pseudo code below. | CVS31.pdf | System | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 22 / page 22 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_INFO 146 RFQX: RFQX-CVS31-0139 | ephemeralPublicKeyServer) ephemeralPublicKeyServer, ephemeralPrivateKeyServer:= Curve25519() sessionKey := X25519(ephemeralPrivateKeyServer, ephemeralPublicKeyClient) sessionKey := X25519(ephemeralPrivateKeyClient , ephemeralPublicKeyServer) ephemeralPublicKeyClient, ephemeralPrivateKeyClient := Curve25519() ProofOfOwnership(...) VerifyCertificate(...) Figure 4 – Overview Ephemeral Diffie-Hellman key-exchange 4.4 External usage of the sessionKey The sessionKey is used outside the Authentication (ISO 14229-1:2020) service and is run through a key derivation function defined in (CVS32) to derive a key that can be used for securedDataTransmission communication. | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS31 > Page 22 / page 22 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 26 RFQX: RFQX-CVS31-0140 | The SessionKey is referred as SecuredDataTransmissionKey in (CVS32). | CVS31.pdf | System | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS31 > Page 22 / page 22 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 24 RFQX: RFQX-CVS31-0141 | The server shall ensure that the sessionKey is exclusively used for the application responsible for communication over securedDataTransmission (CVS32). | CVS31.pdf | Software | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 22 / page 22 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 33 RFQX: RFQX-CVS31-0142 | Solution for a CRNG shall be according to (CVS150). | CVS31.pdf | System | Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement against the mapped feature/architecture element and verify per the test plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 4.5 CRNG / page 22 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_REQ 25 RFQX: RFQX-CVS31-0143 | The server shall always allow the Authentication 0x29 service (ISO 14229-1:2020) regardless of | CVS31.pdf | Software | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 23 / page 23 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_INFO 12 RFQX: RFQX-CVS31-0144 | Example: If the server’s RBACC is for some reason corrupt or misconfigured this would lock out the client from doing diagnostics (the server will refuse all diagnostics). | CVS31.pdf | IT / backend | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS31 > Page 23 / page 23 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 13 RFQX: RFQX-CVS31-0145 | Two passive de-authentication mechanisms are described in (ISO 14229-1:2020). | CVS31.pdf | Process / compliance | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page 4.7 PassiveDeAuthentication / page 23 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 109 RFQX: RFQX-CVS31-0146 | Only Passive time-based de-authentication shall be supported. | CVS31.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | High | Analysis detailsSource section/page CVS31 > Page 23 / page 23 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_REQ 26 RFQX: RFQX-CVS31-0147 | The server shall start the timer (A3) after a valid proofOfOwnership has been received. | CVS31.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 4.7.1 TimeBasedPassiveDeAuthentication / page 23 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 27 RFQX: RFQX-CVS31-0148 | The server shall restart the timer (A3) every time a request is received by the same client. | CVS31.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS31 > Page 23 / page 23 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_INFO 147 RFQX: RFQX-CVS31-0149 | For this requirement, “same client” refers to a request that originates from the same tester address as the tester currently authenticated by the server. | CVS31.pdf | IT / backend | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS31 > Page 23 / page 23 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 148 RFQX: RFQX-CVS31-0150 | When a request is received, authenticated or not, the server upon verifying it is from the same client will restart the timer (A3). | CVS31.pdf | IT / backend | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS31 > Page 23 / page 23 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 28 RFQX: RFQX-CVS31-0151 | If the A3 timer timeouts before a new request is received (from the same client), the server shall invalidate the authentication state. | CVS31.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 23 / page 23 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 29 RFQX: RFQX-CVS31-0152 | The parameter for passive timeout based deAuthenticate shall be decided in the project. | CVS31.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 23 / page 23 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_INFO 14 RFQX: RFQX-CVS31-0153 | The A3 timer differs from S3 timer in terms of expected behavior during timeout and should not be implemented as a single timer. | CVS31.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS31 > Page 23 / page 23 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_INFO 38 RFQX: RFQX-CVS31-0154 | The delay timer represents the required minimum time between verifyCertificateBidirectional | CVS31.pdf | System | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS31 > Page 24 / page 24 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_REQ 133 RFQX: RFQX-CVS31-0155 | The delay timer shall be set to 1 second. | CVS31.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 24 / page 24 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm responsibility allocation, then implement and verify. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_REQ 151 RFQX: RFQX-CVS31-0156 | If the delay timer is not running, the server shall start it as part of verifyCertificateBidirectional request. | CVS31.pdf | IT / backend | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 24 / page 24 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 152 RFQX: RFQX-CVS31-0157 | If the server can determine that a delay is not running after reset, it shall accept a subsequent authentication request without any delay. | CVS31.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 24 / page 24 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_REQ 153 RFQX: RFQX-CVS31-0158 | If the server cannot determine that a delay is not running after reset, it shall not accept a subsequent authentication request without any delay. | CVS31.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 24 / page 24 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| AUTH_INFO 36 RFQX: RFQX-CVS31-0159 | The Authentication completion timer represents the timeframe that the client is allowed to perform proofOfOwnership request after a verifyCertificateBidirectional request. | CVS31.pdf | System | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 4.9 Authentication completion timer / page 24 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 154 RFQX: RFQX-CVS31-0160 | The Authentication completion timer shall be set to 1 minute. | CVS31.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | High | Analysis detailsSource section/page CVS31 > Page 24 / page 24 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_INFO 37 RFQX: RFQX-CVS31-0161 | The Authentication completion timer is started upon positive response for verifyCertificateBidirectional request. | CVS31.pdf | System | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS31 > Page 24 / page 24 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 167 RFQX: RFQX-CVS31-0162 | Migrated Req. into | CVS31.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page Migrated Req. into / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 169 RFQX: RFQX-CVS31-0163 | Added | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page Added / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 12 RFQX: RFQX-CVS31-0164 | Removed AUTH_REQ 137 since it is covered by AUTH_REQ 135 Removed in Annex A the reference to verifyCertificatesUniDirectional since it is not supported | CVS31.pdf | IT / backend | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS31-0165 RFQX: RFQX-CVS31-0165 | Annex B (informative) Change history Release Date Changes The whole standard has been reworked and shall be read in its entirety. | CVS31.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes No supplier action - document reference / boilerplate. Risk / impact Limited; standard implementation and verification risk. |
| AUTH_REQ 4 RFQX: RFQX-CVS31-0166 | to | CVS31.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 159 RFQX: RFQX-CVS31-0167 | Changed tag | CVS31.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 1 RFQX: RFQX-CVS31-0168 | to | CVS31.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 160 RFQX: RFQX-CVS31-0169 | Changed tag | CVS31.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 2 RFQX: RFQX-CVS31-0170 | to | CVS31.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 161 RFQX: RFQX-CVS31-0171 | Changed tag | CVS31.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 3 RFQX: RFQX-CVS31-0172 | to | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 162 RFQX: RFQX-CVS31-0173 | Changed tag | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 5 RFQX: RFQX-CVS31-0174 | to | CVS31.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 163 RFQX: RFQX-CVS31-0175 | Changed tag | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 6 RFQX: RFQX-CVS31-0176 | to | CVS31.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 164 RFQX: RFQX-CVS31-0177 | Changed tag | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 7 RFQX: RFQX-CVS31-0178 | to | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 165 RFQX: RFQX-CVS31-0179 | Changed tag | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 8 RFQX: RFQX-CVS31-0180 | to | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 166 RFQX: RFQX-CVS31-0181 | Changed tag | CVS31.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 12 RFQX: RFQX-CVS31-0182 | to | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 170 RFQX: RFQX-CVS31-0183 | Changed tag | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 10 RFQX: RFQX-CVS31-0184 | to | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 171 RFQX: RFQX-CVS31-0185 | Duplicated AUTH_INFO due to typo. | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 1 RFQX: RFQX-CVS31-0186 | to | CVS31.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 141 RFQX: RFQX-CVS31-0187 | Changed tag | CVS31.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 2 RFQX: RFQX-CVS31-0188 | to | CVS31.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 142 RFQX: RFQX-CVS31-0189 | Changed tag | CVS31.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 3 RFQX: RFQX-CVS31-0190 | to | CVS31.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 143 RFQX: RFQX-CVS31-0191 | Changed tag | CVS31.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 4 RFQX: RFQX-CVS31-0192 | to | CVS31.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 140 RFQX: RFQX-CVS31-0193 | Changed tag | CVS31.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 5 RFQX: RFQX-CVS31-0194 | to | CVS31.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 145 RFQX: RFQX-CVS31-0195 | Changed tag | CVS31.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 11 RFQX: RFQX-CVS31-0196 | to | CVS31.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 146 RFQX: RFQX-CVS31-0197 | Removed Unused reference Fixed wrong cross reference Migrated Annex A “ephemeralPublicKey” into new chapter 3.3 “SessionKey” and added pseudo code for sessionKey Migrated Info into | CVS31.pdf | System | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 135 RFQX: RFQX-CVS31-0198 | Migrated Info into | CVS31.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 136 RFQX: RFQX-CVS31-0199 | Migrated Req. | CVS31.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 167 RFQX: RFQX-CVS31-0200 | Added | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 168 RFQX: RFQX-CVS31-0201 | Added chapter for Certificate validity Added | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 169 RFQX: RFQX-CVS31-0202 | Added | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 137 RFQX: RFQX-CVS31-0203 | Added OID for client authentication Changed | CVS31.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 107 RFQX: RFQX-CVS31-0204 | Fixed typo Changed | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 136 RFQX: RFQX-CVS31-0205 | (Removed “shown in only”) Changed | CVS31.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 60 RFQX: RFQX-CVS31-0206 | (VerifyCertificateres -> VerifyCertificates) Changed Table 5 (lengthofCertificateClient -> lengthOfCertificateClient) Changed Table 6 (lengthOfCertitifacteServer -> lengthOfCertificateServer) Changed | CVS31.pdf | System | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 127 RFQX: RFQX-CVS31-0207 | (fails -> failure) Changed | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 128 RFQX: RFQX-CVS31-0208 | (fails -> failure) Changed Table 7 (EphemeralPublicKeyClient -> ephemeralPublicKeyClient) Removed ambiguity Changed | CVS31.pdf | System | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 12 RFQX: RFQX-CVS31-0209 | Removed | CVS31.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 137 RFQX: RFQX-CVS31-0210 | since it is covered by | CVS31.pdf | IT / backend | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 135 RFQX: RFQX-CVS31-0211 | Removed in Annex A the reference to verifyCertificatesUniDirectional since it is not supported | CVS31.pdf | IT / backend | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 29 / page 29 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 155 RFQX: RFQX-CVS31-0212 | Changed | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page Changed / page 30 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 117 RFQX: RFQX-CVS31-0213 | Changed | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page Changed / page 30 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 45 RFQX: RFQX-CVS31-0214 | Changed | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page Changed / page 30 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 3 RFQX: RFQX-CVS31-0215 | Changed | CVS31.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page Changed / page 30 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 122 RFQX: RFQX-CVS31-0216 | Changed | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page Changed / page 30 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 5 RFQX: RFQX-CVS31-0217 | Changed | CVS31.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page Changed / page 30 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 164 RFQX: RFQX-CVS31-0218 | Changed | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page Changed / page 30 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 9 RFQX: RFQX-CVS31-0219 | Changed | CVS31.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page Changed / page 30 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 136 RFQX: RFQX-CVS31-0220 | Changed | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page Changed / page 30 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 156 RFQX: RFQX-CVS31-0221 | Changed | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page Changed / page 30 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 172 RFQX: RFQX-CVS31-0222 | Added | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page Added / page 30 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 173 RFQX: RFQX-CVS31-0223 | Added | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page Added / page 30 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 6 RFQX: RFQX-CVS31-0224 | Removed | CVS31.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page Removed / page 30 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 175 RFQX: RFQX-CVS31-0225 | Added | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page Added / page 30 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 176 RFQX: RFQX-CVS31-0226 | Added | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page Added / page 30 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 177 RFQX: RFQX-CVS31-0227 | Added | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page Added / page 30 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 147 RFQX: RFQX-CVS31-0228 | and | CVS31.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS31 > Page 30 / page 30 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 147 RFQX: RFQX-CVS31-0229 | Updated document quirks chapter Removed the information that italic terms are often clickable. | CVS31.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS31 > Page 30 / page 30 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 1 RFQX: RFQX-CVS31-0230 | Reformulation for clarity improvement Changed | CVS31.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS31 > Page 30 / page 30 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 155 RFQX: RFQX-CVS31-0231 | Changed | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 30 / page 30 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 117 RFQX: RFQX-CVS31-0232 | Changed | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 30 / page 30 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 24 RFQX: RFQX-CVS31-0233 | Changed | CVS31.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS31 > Page 30 / page 30 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 45 RFQX: RFQX-CVS31-0234 | Changed | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 30 / page 30 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 3 RFQX: RFQX-CVS31-0235 | Changed | CVS31.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS31 > Page 30 / page 30 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 122 RFQX: RFQX-CVS31-0236 | Changed | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 30 / page 30 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 5 RFQX: RFQX-CVS31-0237 | Changed | CVS31.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS31 > Page 30 / page 30 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 164 RFQX: RFQX-CVS31-0238 | Changed | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 30 / page 30 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 9 RFQX: RFQX-CVS31-0239 | Changed | CVS31.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS31 > Page 30 / page 30 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 136 RFQX: RFQX-CVS31-0240 | Changed | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 30 / page 30 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 156 RFQX: RFQX-CVS31-0241 | Changed | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 30 / page 30 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 157 RFQX: RFQX-CVS31-0242 | Changed Table 3 (Authentication pending state and authentication state) Changed Table 5 (Changed column name POO -> proofOfOwnershipServer) Changed Table 6 (Changed column name POO -> proofOfOwnershipServer) Changed | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 30 / page 30 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 24 RFQX: RFQX-CVS31-0243 | (Changed POO -> proofOfOwnershipServer) Removed | CVS31.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS31 > Page 30 / page 30 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 171 RFQX: RFQX-CVS31-0244 | (Maximum size of elements is to be defined by max size of certificate) Added | CVS31.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 30 / page 30 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 100 RFQX: RFQX-CVS31-0245 | (Maximum size of elements is to be defined by max size of certificate) Updated Figure 3 Reformulation requirements over the length of client certificate Removed | CVS31.pdf | Cybersecurity | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS31 > Page 30 / page 30 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 108 RFQX: RFQX-CVS31-0246 | Added Chapter 2.1.1.2 lengthOfCertificateClient Added | CVS31.pdf | System | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS31 > Page 30 / page 30 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 172 RFQX: RFQX-CVS31-0247 | Added | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 30 / page 30 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 173 RFQX: RFQX-CVS31-0248 | Added | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 30 / page 30 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 174 RFQX: RFQX-CVS31-0249 | Clarified the signature algorithm to be used over the authentication process Removed | CVS31.pdf | Process / compliance | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | High | Analysis detailsSource section/page CVS31 > Page 30 / page 30 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 6 RFQX: RFQX-CVS31-0250 | Added | CVS31.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS31 > Page 30 / page 30 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 175 RFQX: RFQX-CVS31-0251 | Added | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 30 / page 30 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 176 RFQX: RFQX-CVS31-0252 | Added | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 30 / page 30 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_REQ 177 RFQX: RFQX-CVS31-0253 | Added | CVS31.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS31 > Page 30 / page 30 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| AUTH_INFO 101 RFQX: RFQX-CVS31-0254 | 2025-08 CVS31 First edition 2025-05-30 RFQ 2517 Delivery Added authentication delay timer Added Authentication Completion timer Clarified negative responses cases for each subfunction | CVS31.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS31 > Page 30 / page 30 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS32-0001 RFQX: RFQX-CVS32-0001 | The User shall apply the latest version of this CVS32. | CVS32.pdf | System | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS32 > Page 1 / page 1 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS32-0002 RFQX: RFQX-CVS32-0002 | Foreword This CVS32 contains requirement specification for TRATON GROUP and may be used by all within TRATON Group, if applicable. | CVS32.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS32 > Page 2 / page 2 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No supplier action - document reference / boilerplate. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS32-0003 RFQX: RFQX-CVS32-0003 | 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”. | CVS32.pdf | Process / compliance | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS32 > Page 2 / page 2 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| RFQX-CVS32-0004 RFQX: RFQX-CVS32-0004 | • 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. | CVS32.pdf | IT / backend | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS32 > Page 2 / page 2 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| 1.1 RFQX: RFQX-CVS32-0005 | The purpose of this document is to clarify vehicle manufacturer specific extensions and exceptions to the SecuredDataTransmission 0x84 service specified in ISO14229-1:2020 [1]. This specification does not include any redundant requirements of the normative and indispensable documents referenced below. It contains only clarifications of the requirements and recommendations in these documents together with exceptions and additional requirements that apply to this standard in relation to these documents. The following documents are normative and indispensable for the application of this document: • TRATON Specification on Unified diagnostic Services (UDS) requirements [8] • ISO 14229-1:2020, Road vehicles — Unified diagnostic services (UDS) — Part 1: Specification and requirements [1] | CVS32.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 4 / page 4 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No supplier action - document reference / boilerplate. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 1.2 RFQX: RFQX-CVS32-0006 | The target readers for this specification are ECU-suppliers and ECU-developers in reference to the server-side requirements, and diagnostic tool developers and back-end service providers regarding the client-side requirements. These “target readers” can be either internal or external in relation to the vehicle manufacturer. | CVS32.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 4 / page 4 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| 1.3 RFQX: RFQX-CVS32-0007 | The mnemonics defined in the ISO14229-1:2020 [1] standard are reused throughout this document. Some paragraphs in this document includes pseudo code. The pseudo code make use of the following notation: 𝑋 || 𝑌 The concatenation of the octet strings 𝑋 and 𝑌 𝑋𝑠𝑒𝑟𝑣𝑒𝑟 𝑋 is owned by the Server 𝑋𝑐𝑙𝑖𝑒𝑛𝑡 𝑋 is owned by the Client The first occurrence of an abbreviation or term in this document will appear italicized to indicate that it is explained in section 1.4 Abbreviations or section 1.5 Terminology. All paragraphs from here on in this document are assigned unique tags, composed of a prefix and an identification number for non-ambiguous identification. SDT_REQ X identifies a requirement, and tag SDT_INFO X is used to denote informational text. Whether a requirement refers to client-side or server-side behavior is clear from the context and the requirement text itself. 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]. | CVS32.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 4 / page 4 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RFQX-CVS32-0008 RFQX: RFQX-CVS32-0008 | 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]. | CVS32.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS32 > Page 4 / page 4 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| SDT_REQ 1 RFQX: RFQX-CVS32-0009 | The implementation of SDT (SecuredDataTransmission) shall follow the information provided in | CVS32.pdf | System | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS32 > Page 6 / page 6 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_INFO 1 RFQX: RFQX-CVS32-0010 | Although SDT (service 0x84) is of course part of UDS, in this document, SDT is treated much like a transport layer for other UDS services. | CVS32.pdf | Software | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page Figure 1 – SDT Overview / page 6 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 2 RFQX: RFQX-CVS32-0011 | Figure 1 shows the layout of an SDT message with its protocol elements (for details refer to ISO 14229-1:2020 [1]). | CVS32.pdf | Interface | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS32 > Page 6 / page 6 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 2 RFQX: RFQX-CVS32-0012 | Whenever a requirement in this document deviates from requirements in ISO14229-1 [1] the requirements of this document shall take precedence. | CVS32.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS32 > Page 6 / page 6 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 3 RFQX: RFQX-CVS32-0013 | ECUs with diagnostic servers in multiple execution states, e.g. | CVS32.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 6 / page 6 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS32-0014 RFQX: RFQX-CVS32-0014 | one diagnostic server in the boot-loader and one in the application, shall support SDT in all execution states. | CVS32.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS32 > Page 6 / page 6 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_INFO 3 RFQX: RFQX-CVS32-0015 | A prerequisite for the SDT service is that a SecuredDataTransmissionKey has been established between client and server using the 0x29 service [6]. | CVS32.pdf | Software | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS32 > Page 6 / page 6 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 4 RFQX: RFQX-CVS32-0016 | The SDT server shall use the diagnostic tester address of the SDT client to identify the authentication state and hence the SecuredDataTransmissionKey. | CVS32.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 6 / page 6 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RFQX-CVS32-0017 RFQX: RFQX-CVS32-0017 | (There may be more than one authentication state). | CVS32.pdf | System | Source classifies this as Unknown (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | High | Analysis detailsSource section/page CVS32 > Page 6 / page 6 Pre-analysis Source classifies this as Unknown (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 4 RFQX: RFQX-CVS32-0018 | The number of concurrently active SDT sequences is limited by the number of authentication states that a server is allowed to maintain, refer to [6]. | CVS32.pdf | IT / backend | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS32 > Page 7 / page 7 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 5 RFQX: RFQX-CVS32-0019 | The server shall not allow an SDT message with service 0x84 as the application layer service (service 0x84 encapsulated inside another service 0x84). | CVS32.pdf | Software | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS32 > Page 7 / page 7 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| RFQX-CVS32-0020 RFQX: RFQX-CVS32-0020 | The server shall respond with application layer NRC 0x39, i.e. | CVS32.pdf | Software | Binding, non-security requirement with feature/architecture traceability. | 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. | Implement against the mapped feature/architecture element and verify per the test plan. | BLOCKED BY CUSTOMER DECISION | NEEDS REVIEW | Analysis detailsSource section/page CVS32 > Page 7 / page 7 Pre-analysis Binding, non-security requirement with feature/architecture traceability. Assumptions Customer confirms responsibility allocation and implementation method. Engineering notes Confirm with customer whether this is a binding requirement and assign a customer ID. Risk / impact Limited; standard implementation and verification risk. |
| SDT_INFO 5 RFQX: RFQX-CVS32-0021 | 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 Anti-replay protection for SDT messages is provided by the ANTIREPLAYCNT protocol element. | CVS32.pdf | Interface | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS32 > Page 7 / page 7 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Limited; standard implementation and verification risk. |
| SDT_INFO 6 RFQX: RFQX-CVS32-0022 | This specification defines two counters, one for the request messages and one for responses. | CVS32.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS32 > Page 7 / page 7 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 7 RFQX: RFQX-CVS32-0023 | The reason for the two separate counters is that the UDS standard allows for a request to result in multiple responses, e.g. | CVS32.pdf | System | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS32 > Page 7 / page 7 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 8 RFQX: RFQX-CVS32-0024 | The state variables needed to keep track of these counters are called PREQARC (Previous REQuest Anti-Replay Counter) and PRESARC (Previous RESponse Anti-Replay Counter). | CVS32.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS32 > Page 7 / page 7 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 6 RFQX: RFQX-CVS32-0025 | Both client and server shall maintain instances of the state variables PREQARC and PRESARC. | CVS32.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS32 > Page 7 / page 7 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_REQ 7 RFQX: RFQX-CVS32-0026 | At construction of an SDT request, the client shall increment PREQARC by one (1) and populate the ANTIREPLAYCNT protocol element with the resulting value. | CVS32.pdf | Interface | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS32 > Page 7 / page 7 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 8 RFQX: RFQX-CVS32-0027 | 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. | CVS32.pdf | IT / backend | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 7 / page 7 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_REQ 9 RFQX: RFQX-CVS32-0028 | At construction of an SDT response, the server shall increment PRESARC by one (1) and populate the ANTIREPLAYCNT protocol element with the resulting value. | CVS32.pdf | IT / backend | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS32 > Page 7 / page 7 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_REQ 10 RFQX: RFQX-CVS32-0029 | 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. | CVS32.pdf | Interface | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 7 / page 7 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 11 RFQX: RFQX-CVS32-0030 | The client should populate the ANTIREPLAYCNT protocol element of the first request of an | CVS32.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS32 > Page 8 / page 8 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 12 RFQX: RFQX-CVS32-0031 | 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. | CVS32.pdf | IT / backend | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS32 > Page 8 / page 8 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_INFO 9 RFQX: RFQX-CVS32-0032 | It is good practise to start a sequence with ANTIREPLAYCNT set to zero (0), but this is not something that is enforced by the recipient of the message, be it the first request or response. | CVS32.pdf | IT / backend | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS32 > Page 8 / page 8 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 13 RFQX: RFQX-CVS32-0033 | If either PREQARC or PRESARC reaches the maximum value 65535 (0xFFFF), the client shall re-authenticate if it wishes to send more messages. | CVS32.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS32 > Page 8 / page 8 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_INFO 10 RFQX: RFQX-CVS32-0034 | The server handles the exhaustion of PREQARC and PRESARC with its “normal behavior”. | CVS32.pdf | IT / backend | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS32 > Page 8 / page 8 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 71 RFQX: RFQX-CVS32-0035 | ). | CVS32.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page If the ANTIREPLAYCNT in a request is less than or equal to PREQARC, the request is rejected ( / page 8 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 9 RFQX: RFQX-CVS32-0036 | ). | CVS32.pdf | IT / backend | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page If PRESARC is exhausted, the server can no longer respond ( / page 8 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 11 RFQX: RFQX-CVS32-0037 | The requirements above are illustrated in Figure 2. | CVS32.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page Figure 2 – Anti-replay protection / page 8 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 12 RFQX: RFQX-CVS32-0038 | Apart from ensuring that old messages are not replayed, it is also necessary for the client to be able to determine that an incoming response is actually a response to the request that is currently outstanding. | CVS32.pdf | IT / backend | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS32 > Page 8 / page 8 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 13 RFQX: RFQX-CVS32-0039 | Since any CipherScheme supported by this specification will at least authenticate messages, there will always be a TAG (MAC or similar) populated in the SIGMACBYTE protocol element of all SDT messages. This TAG is used to guarantee request/response coherency and the corresponding state variable is called PREQTAG (Previous REQuest TAG). | CVS32.pdf | Interface | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS32 > Page 9 / page 9 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 14 RFQX: RFQX-CVS32-0040 | The client shall maintain the state variable PREQTAG. | CVS32.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS32 > Page 9 / page 9 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_INFO 14 RFQX: RFQX-CVS32-0041 | The requirements regarding PREQTAG are detailed in sections 3.2.2 and 3.2.3 since they differ slightly between CipherSchemes. | CVS32.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS32 > Page 9 / page 9 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 15 RFQX: RFQX-CVS32-0042 | Figure 3 illustrates transaction coherency and the use of PREQTAG. | CVS32.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page Figure 3 – Anti-replay protection and transaction coherency / page 9 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 16 RFQX: RFQX-CVS32-0043 | The authenticity, and optionally confidentiality, of an SDT message is provided by the CipherScheme with which the SDT message is authenticated/encrypted. | CVS32.pdf | Interface | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 3.2 Authenticity and Confidentiality / page 9 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 15 RFQX: RFQX-CVS32-0044 | The CipherScheme used when constructing an SDT message shall be indicated by the SIGENCRYPT protocol element according to Table 2. | CVS32.pdf | Interface | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS32 > Page 9 / page 9 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_INFO 17 RFQX: RFQX-CVS32-0045 | The supported CipherSchemes SDT_AEAD_CHACHA20_POLY1305 and SDT_POLY1305 [9] are described in sections 3.2.2 and 3.2.3 respectively. The two CipherSchemes require different key material. The Key Derivation Function (KDF) is described in section 3.2.1. | CVS32.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS32 > Page 10 / page 10 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 16 RFQX: RFQX-CVS32-0046 | The CipherSchemes SDT_AEAD_CHACHA20_POLY1305 and SDT_POLY1305 shall be supported. | CVS32.pdf | System | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS32 > Page 10 / page 10 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 17 RFQX: RFQX-CVS32-0047 | At SDT message reception, the recipient shall verify/decrypt the message using the CipherScheme indicated by the SIGENCRYPT protocol element. | CVS32.pdf | Interface | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS32 > Page 10 / page 10 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 18 RFQX: RFQX-CVS32-0048 | In case of a positive SDT response, the server shall respond to a client request with the same CipherScheme used in the request. | CVS32.pdf | IT / backend | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS32 > Page 10 / page 10 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_REQ 19 RFQX: RFQX-CVS32-0049 | The client may alter the CipherScheme between SDT requests within the same SDT sequence. | CVS32.pdf | System | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS32 > Page 10 / page 10 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 18 RFQX: RFQX-CVS32-0050 | Since the two CipherSchemes require different key material, the KDF has to be re-run if the CipherScheme changes. | CVS32.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS32 > Page 10 / page 10 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 20 RFQX: RFQX-CVS32-0051 | Client and server should keep state variables that indicate which CipherScheme, and resulting key, was used in the previous SDT transaction. | CVS32.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 10 / page 10 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_INFO 19 RFQX: RFQX-CVS32-0052 | In the following, these state variables are called PSIGENCRYPT (Previous SIGENCRYPT) and PKEY (Previous KEY). | CVS32.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS32 > Page 10 / page 10 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 21 RFQX: RFQX-CVS32-0053 | 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. | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 10 / page 10 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 22 RFQX: RFQX-CVS32-0054 | 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. | CVS32.pdf | IT / backend | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 10 / page 10 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_INFO 20 RFQX: RFQX-CVS32-0055 | Figure 4 illustrates the switching of CipherSchemes within an SDT sequence. The client has previously used CipherScheme 3, and for request X+1, switches to 2. The server reacts on the different SIGENCRYPT and updates its state accordingly. Client Server PREQARC = X | CVS32.pdf | IT / backend | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS32 > Page 11 / page 11 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 23 RFQX: RFQX-CVS32-0056 | 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 Client and server shall support the HKDF [2] key derivation function using HMAC-SHA512 [3]. | CVS32.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 11 / page 11 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_REQ 24 RFQX: RFQX-CVS32-0057 | ikm : The ikm argument to the HKDF function shall be the octet string containing the SecuredDataTransmissionKey from the service 0x29 authentication state. | CVS32.pdf | Software | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 𝐻𝐾𝐷𝐹(𝑖𝑘𝑚, 𝑠𝑎𝑙𝑡, 𝑖𝑛𝑓𝑜, 𝐿) → 𝑜𝑘𝑚 / page 11 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 25 RFQX: RFQX-CVS32-0058 | salt: The salt argument to the HKDF function shall be set as the zero length octet string (null). | CVS32.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS32 > Page 11 / page 11 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 26 RFQX: RFQX-CVS32-0059 | 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. | CVS32.pdf | Software | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 11 / page 11 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_INFO 21 RFQX: RFQX-CVS32-0060 | Example: “SDT_0x84_KEY” = 5344545F307838345F4B4559 (UTF-8 encoded hex) CipherScheme = 02 (SDT_AEAD_CHACHA20_POLY1305) ➔ info := 5344545F307838345F4B455902 | CVS32.pdf | System | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS32 > Page 11 / page 11 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 22 RFQX: RFQX-CVS32-0061 | L: The L argument determines the length of okm and is determined by whichever CipherScheme to be used, see sections 3.2.2 and 3.2.3. | CVS32.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS32 > Page 11 / page 11 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 23 RFQX: RFQX-CVS32-0062 | okm is the output key material octet string of length L. | CVS32.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS32 > Page 12 / page 12 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 24 RFQX: RFQX-CVS32-0063 | This section describes a CipherScheme based on AEAD_CHACHA20_POLY1305 [9]. | CVS32.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 3.2.2 SDT_AEAD_CHACHA20_POLY1305 / page 12 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 27 RFQX: RFQX-CVS32-0064 | The L argument to the HKDF function shall be set to 64. | CVS32.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS32 > Page 12 / page 12 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 28 RFQX: RFQX-CVS32-0065 | Octets 0-31 of the okm shall be used as key by the client to encrypt, and the server to decrypt, the request. | CVS32.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 12 / page 12 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_REQ 29 RFQX: RFQX-CVS32-0066 | Octets 32-63 of the okm shall be used as key by the server to encrypt, and the client to decrypt, the response. | CVS32.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 12 / page 12 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_INFO 25 RFQX: RFQX-CVS32-0067 | The above requirements are visualized in Figure 5. | CVS32.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS32 > Page 12 / page 12 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 30 RFQX: RFQX-CVS32-0068 | 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: 𝐾: The 𝐾 argument shall be the key octet string of 32 octets. | CVS32.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 12 / page 12 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| SDT_REQ 31 RFQX: RFQX-CVS32-0069 | 𝑁: 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. | CVS32.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS32 > Page 12 / page 12 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 32 RFQX: RFQX-CVS32-0070 | 𝑃: The 𝑃 (Plaintext) argument shall be the octet string that is the concatenation of the INTMSGREQID and SRVSPECPARAM. | CVS32.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS32 > Page 12 / page 12 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 33 RFQX: RFQX-CVS32-0071 | 𝐶: When injected into, or extracted from an SDT message, the first octet of 𝐶 shall correspond to INTMSGREQID, and the remaining octets to SRVSPECPARAM. | CVS32.pdf | Interface | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS32 > Page 12 / page 12 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_INFO 26 RFQX: RFQX-CVS32-0072 | The plaintext (𝑃) and ciphertext (𝐶) octet strings are of the same length and a concatenation of the INTMSGREQID and SRVSPECPARAM protocol elements. | CVS32.pdf | Interface | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS32 > Page 12 / page 12 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 34 RFQX: RFQX-CVS32-0073 | The client shall encrypt and authenticate the SDT request with the 𝐴 argument set to the | CVS32.pdf | Cybersecurity | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS32 > Page 13 / page 13 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| SDT_REQ 35 RFQX: RFQX-CVS32-0074 | The client shall populate the APAR protocol element in the request so that bits 0, 4, 5 and 6 are set to true. | CVS32.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS32 > Page 13 / page 13 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 36 RFQX: RFQX-CVS32-0075 | The client shall populate the SIGLEN protocol element in the request with 16 (0x0010). | CVS32.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS32 > Page 13 / page 13 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 37 RFQX: RFQX-CVS32-0076 | The client shall populate the SIGMACBYTE protocol element in the request with 𝑇𝐴𝐺. | CVS32.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS32 > Page 13 / page 13 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 38 RFQX: RFQX-CVS32-0077 | The client shall store 𝑇𝐴𝐺 in its state variable PREQTAG. | CVS32.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS32 > Page 13 / page 13 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 39 RFQX: RFQX-CVS32-0078 | 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑑𝑒𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴, 𝐶, 𝑇𝐴𝐺) → 𝑜𝑘/𝑛𝑜𝑘, 𝑃 The client shall decrypt and verify the SDT response with: 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. | CVS32.pdf | Interface | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS32 > Page 13 / page 13 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 41 RFQX: RFQX-CVS32-0079 | element of the response. | CVS32.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS32 > Page 13 / page 13 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 42 RFQX: RFQX-CVS32-0080 | 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. | CVS32.pdf | IT / backend | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 3.2.2.2 Server Decryption/Encryption 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑑𝑒𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴, 𝐶, 𝑇𝐴𝐺) → 𝑜𝑘/𝑛𝑜𝑘, 𝑃 / page 13 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_REQ 43 RFQX: RFQX-CVS32-0081 | element of the request. | CVS32.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS32 > Page 13 / page 13 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 44 RFQX: RFQX-CVS32-0082 | 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑒𝑛𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴, 𝑃) → 𝐶, 𝑇𝐴𝐺 The server shall encrypt and authenticate the SDT response with: 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. | CVS32.pdf | Cybersecurity | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS32 > Page 13 / page 13 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_REQ 46 RFQX: RFQX-CVS32-0083 | The server shall populate the APAR protocol element in the response so that bits 4 and 5 are set to true. | CVS32.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS32 > Page 13 / page 13 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_REQ 47 RFQX: RFQX-CVS32-0084 | The server shall populate the SIGLEN protocol element in the request with 16 (0x0010). | CVS32.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS32 > Page 14 / page 14 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_REQ 48 RFQX: RFQX-CVS32-0085 | The server shall populate the SIGMACBYTE protocol element in the request with 𝑇𝐴𝐺. | CVS32.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS32 > Page 14 / page 14 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_INFO 27 RFQX: RFQX-CVS32-0086 | 0x84 0x02 xx x X+1 SDT APAR 0x84 0x02 xx x X+1 0xC4 0x02 xxxxxxxxxx x Y+1 0xC4 0x02 xxxxxxxxxx x Y+1 SDTPR APAR RDBI SNOETDID 0 633132 KeyrequestHKDF(ikm, salt, info, 64) -> C TAG || CHACHA20-POLY1305enrypt(Keyrequest, N, A, P)-> CHACHA20-POLY1305decrypt(Keyrequest, N, A, C, TAG)-> S Keyresponse SecuredDataTransmissionKey (ikm) from 0x29 service Client s state variables PREQTAG=TAG_X Server s state variables C 0x22 || Application layer P A || || RDBI0x22 Application layer SNOETDID S C TAG P A CHACHA20-POLY1305enrypt(Keyresponse, N, A, P)-> RDBIPR0x62 0xF19743564320435 64331 SNOETDID Application layer || C TAG S C 6 A || CHACHA20-POLY1305decrypt(Keyresponse, N, A, C, TAG)-> || || RDBIPR SNOETDID 0x62 0xF19743564320435 64331 Application layer S P P ||X+1 N ||X+1 N Y+1 || N ||Y+1 Figure 6 – Example of client and server's behavior using SDT_AEAD_CHACHA20_POLY1305 The example in Figure 6 shows an AEAD_CHACHA20_POLY1305 authenticated and encrypted SDT transaction. | CVS32.pdf | Software | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS32 > Page 14 / page 14 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 28 RFQX: RFQX-CVS32-0087 | The encircled “||” denotes concatenation and the concatenation order is top to bottom in the figure. | CVS32.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS32 > Page 14 / page 14 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS32-0088 RFQX: RFQX-CVS32-0088 | one octet, and the rest should go in the SRVSPECPARAM protocol element. | CVS32.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS32 > Page 14 / page 14 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_INFO 29 RFQX: RFQX-CVS32-0089 | Encrypted data in the figure is denoted “x..x”, one “x” denotes one encrypted octet. | CVS32.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS32 > Page 14 / page 14 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 30 RFQX: RFQX-CVS32-0090 | This section describes a CipherScheme based on the AEAD_CHACHA20_POLY1305 [9] algorithm. Note that in this CipherScheme we only use the authentication properties of AEAD_CHACHA20_POLY1305 i.e., no encryption/decryption. The requirements in this section are visualized with an example in Figure 8. | CVS32.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS32 > Page 15 / page 15 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 49 RFQX: RFQX-CVS32-0091 | The L argument to the HKDF function shall be set to 64. | CVS32.pdf | Software | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS32 > Page 15 / page 15 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 50 RFQX: RFQX-CVS32-0092 | Octets 0-31 of the okm shall be used as key by the client to authenticate, and the server to verify, the request. | CVS32.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 15 / page 15 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_REQ 51 RFQX: RFQX-CVS32-0093 | Octets 32-63 of the okm shall be used as key by the server to authenticate, and the client to verify, the response. | CVS32.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 15 / page 15 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_INFO 49 RFQX: RFQX-CVS32-0094 | The above requirements are visualized in Figure 7. | CVS32.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS32 > Page 15 / page 15 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 52 RFQX: RFQX-CVS32-0095 | 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: 𝐾: The 𝐾 argument shall be the key octet string of 32 octets. | CVS32.pdf | Cybersecurity | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 15 / page 15 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| SDT_REQ 91 RFQX: RFQX-CVS32-0096 | 𝑁: 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. | CVS32.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS32 > Page 15 / page 15 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Linked source table/diagram context was considered for interpretation. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 89 RFQX: RFQX-CVS32-0097 | 𝑃: The 𝑃 (Plaintext) is a zero length octet string (null). | CVS32.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS32 > Page 15 / page 15 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 90 RFQX: RFQX-CVS32-0098 | 𝐶: The 𝐶 (Ciphertext) is a zero length octet string (null). | CVS32.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS32 > Page 15 / page 15 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 54 RFQX: RFQX-CVS32-0099 | The client shall authenticate the SDT request with the 𝐴 argument set to the octet string | CVS32.pdf | System | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS32 > Page 16 / page 16 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 55 RFQX: RFQX-CVS32-0100 | The client shall populate the APAR protocol element in the request so that bits 0, 5 and 6 are set to true. | CVS32.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS32 > Page 16 / page 16 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 56 RFQX: RFQX-CVS32-0101 | The client shall populate the SIGLEN protocol element in the request with 16 (0x0010). | CVS32.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS32 > Page 16 / page 16 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 57 RFQX: RFQX-CVS32-0102 | The client shall populate the SIGMACBYTE protocol element in the request with 𝑇𝐴𝐺. | CVS32.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS32 > Page 16 / page 16 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 58 RFQX: RFQX-CVS32-0103 | The client shall store 𝑇𝐴𝐺 in its state variable PREQTAG. | CVS32.pdf | System | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS32 > Page 16 / page 16 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 59 RFQX: RFQX-CVS32-0104 | 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. | CVS32.pdf | Interface | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑣𝑒𝑟𝑖𝑓𝑦(𝐾, 𝑁, 𝐴, 𝐶𝑛𝑢𝑙𝑙, 𝑇𝐴𝐺) → ok/nok,𝑃𝑛𝑢𝑙𝑙 / page 16 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 60 RFQX: RFQX-CVS32-0105 | element of the response. | CVS32.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page That is: 𝐴 ≔ (𝑆𝐷𝑇 𝑟𝑒𝑠𝑝𝑜𝑛𝑠𝑒 − 𝑆𝐼𝐺𝑀𝐴𝐶𝐵𝑌𝑇𝐸)||𝑃𝑅𝐸𝑄𝑇𝐴𝐺 / page 16 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 61 RFQX: RFQX-CVS32-0106 | 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. | CVS32.pdf | IT / backend | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page 3.2.3.2 Server Verification/Authentication 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑣𝑒𝑟𝑖𝑓𝑦(𝐾, 𝑁, 𝐴, 𝐶𝑛𝑢𝑙𝑙, 𝑇𝐴𝐺) → ok/nok,𝑃𝑛𝑢𝑙𝑙 / page 16 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_REQ 62 RFQX: RFQX-CVS32-0107 | element of the request. | CVS32.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS32 > Page 16 / page 16 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 63 RFQX: RFQX-CVS32-0108 | 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. | CVS32.pdf | IT / backend | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑎𝑢𝑡ℎ𝑒𝑛𝑡𝑖𝑐𝑎𝑡𝑒(𝐾, 𝑁, 𝐴, 𝑃𝑛𝑢𝑙𝑙) → 𝐶𝑛𝑢𝑙𝑙, 𝑇𝐴𝐺 / page 16 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_REQ 64 RFQX: RFQX-CVS32-0109 | The server shall populate the APAR protocol element in the response so that bit 5 is set to true. | CVS32.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS32 > Page 17 / page 17 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_REQ 65 RFQX: RFQX-CVS32-0110 | The server shall populate the SIGLEN protocol element in the response with 16 (0x0010). | CVS32.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS32 > Page 17 / page 17 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_REQ 66 RFQX: RFQX-CVS32-0111 | The client shall populate the SIGMACBYTE protocol element in the response with 𝑇𝐴𝐺. | CVS32.pdf | Interface | Security-relevant requirement the ECU can own once responsibility/method is confirmed. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS32 > Page 17 / page 17 Pre-analysis Security-relevant requirement the ECU can own once responsibility/method is confirmed. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_INFO 31 RFQX: RFQX-CVS32-0112 | 0x84 0x03 0x22 X+1 SDT APAR 0x84 0x03 0x22 X+1 0xC4 0x03 0xF1974356432043564331 0x62 Y+1 0xC4 0x03 0xF1974356432043564331 0x62 Y+1 SDTPR APAR 0 633132 KeyrequestHKDF(ikm, salt, info, 64) -> null TAG || CHACHA20-POLY1305authenticate(Keyrequest, N, A, null)-> CHACHA20-POLY1305verify(Keyrequest, N, A, null, TAG)-> ok Keyresponse SecuredDataTransmissionKey (ikm) from 0x29 service Client s state variables PREQTAG=TAG_X Server s state variables A || TAG A CHACHA20-POLY1305authenticate(Keyresponse, N, A, null)-> || null TAG 8 A CHACHA20-POLY1305verify(Keyrequest, N, A, null, TAG)-> ok || TAG A 8 ||X+1 N ||X+1 N ||Y+1 N ||Y+1 N Figure 8 – Example of client and server's behavior using SDT_POLY1305 The example in Figure 8 shows an AEAD_CHACHA20_POLY1305 authenticated SDT transaction. | CVS32.pdf | Software | Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS32 > Page 17 / page 17 Pre-analysis Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 32 RFQX: RFQX-CVS32-0113 | The encircled “||” denotes concatenation and the concatenation order is top to bottom relative the symbol. | CVS32.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS32 > Page 17 / page 17 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 33 RFQX: RFQX-CVS32-0114 | This specification is mainly concerned with errors generated or detected by the client and server’s security sub-layer [1]. General UDS error handling is out of scope of this document. Figure 9 shows how the different “layers”1 interact conceptually. | CVS32.pdf | Cybersecurity | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS32 > Page 18 / page 18 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 34 RFQX: RFQX-CVS32-0115 | A UDS request/response, in the figure, means any request/response other than SDT (service 0x84). | CVS32.pdf | Software | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS32 > Page 18 / page 18 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| RFQX-CVS32-0116 RFQX: RFQX-CVS32-0116 | The SDT positive response may of course contain an encapsulated negative UDS response. | CVS32.pdf | System | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS32 > Page 18 / page 18 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 35 RFQX: RFQX-CVS32-0117 | Figure 10Figure 10 illustrates error- and state handling in the server’s security sub-layer. | CVS32.pdf | Cybersecurity | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page Figure 9 – Conceptual overview of SDT error handling 3.3.1 Server’s Behaviour / page 18 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 36 RFQX: RFQX-CVS32-0118 | Note that the markings in the figure, (“S1” through “S3”), and the values for the state variables are correlated with Figure 3. | CVS32.pdf | System | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS32 > Page 18 / page 18 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 67 RFQX: RFQX-CVS32-0119 | Other than the NRCs 0x3A, 0x13 and 0x21, specified by ISO14229-1:2020 [1], the server shall support the NRC 0x34 “authenticationRequired”. | CVS32.pdf | IT / backend | Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 18 / page 18 Pre-analysis Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_REQ 68 RFQX: RFQX-CVS32-0120 | At reception of an SDT request, if the security sub-layer is busy, the server shall respond with | CVS32.pdf | Cybersecurity | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS32 > Page 19 / page 19 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_REQ 69 RFQX: RFQX-CVS32-0121 | 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. | CVS32.pdf | IT / backend | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS32 > Page 19 / page 19 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_REQ 70 RFQX: RFQX-CVS32-0122 | 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. | CVS32.pdf | IT / backend | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS32 > Page 20 / page 20 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_REQ 71 RFQX: RFQX-CVS32-0123 | At reception of an SDT request, if ANTIREPLAYCNT ≤ PREQARC, the server shall respond with an SDT negative response using the NRC 0x3A. | CVS32.pdf | IT / backend | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS32 > Page 20 / page 20 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_REQ 88 RFQX: RFQX-CVS32-0124 | At reception of an SDT request, if PRESARC is exhausted, the server shall respond with an SDT negative response using the NRC 0x3A. | CVS32.pdf | IT / backend | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS32 > Page 20 / page 20 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_REQ 72 RFQX: RFQX-CVS32-0125 | At reception of an SDT request, if SIGENCRYPT is not supported, the server shall respond with an SDT negative response using the NRC 0x3A. | CVS32.pdf | IT / backend | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS32 > Page 20 / page 20 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_REQ 73 RFQX: RFQX-CVS32-0126 | 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. | CVS32.pdf | IT / backend | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS32 > Page 20 / page 20 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_INFO 37 RFQX: RFQX-CVS32-0127 | For example, APAR dictates encryption, but SIGENCRYPT does not offer encryption. | CVS32.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS32 > Page 20 / page 20 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 74 RFQX: RFQX-CVS32-0128 | 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. | CVS32.pdf | IT / backend | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS32 > Page 20 / page 20 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_INFO 38 RFQX: RFQX-CVS32-0129 | For example, the CipherScheme indicated by SIGENCRYPT produces a TAG of a length different from that indicated by SIGLEN. | CVS32.pdf | System | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS32 > Page 20 / page 20 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 75 RFQX: RFQX-CVS32-0130 | 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. | CVS32.pdf | IT / backend | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS32 > Page 20 / page 20 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_REQ 76 RFQX: RFQX-CVS32-0131 | 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. | CVS32.pdf | IT / backend | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 20 / page 20 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_INFO 39 RFQX: RFQX-CVS32-0132 | This means that if the server generates an SDT negative response, the server’s state remains unchanged, i.e. | CVS32.pdf | IT / backend | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS32 > Page 20 / page 20 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 77 RFQX: RFQX-CVS32-0133 | The server shall update its state, (increment PRESARC by one (1)), if and only if it can successfully authenticate/encrypt the SDT response (“S3”). | CVS32.pdf | Cybersecurity | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 20 / page 20 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_INFO 40 RFQX: RFQX-CVS32-0134 | This means that if the server fails to generate an SDT response, the server’s state remains unchanged, i.e. | CVS32.pdf | IT / backend | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS32 > Page 20 / page 20 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 41 RFQX: RFQX-CVS32-0135 | As mentioned above in this specification, the UDS standard allows for a request to result in multiple responses, e.g. | CVS32.pdf | System | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page 3.3.1.1 SDT transactions with multiple responses / page 20 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 42 RFQX: RFQX-CVS32-0136 | Figure 11 shows an example where the client sends a RDBI and the server responds with two instances of RCRRP before delivering the final response. | CVS32.pdf | IT / backend | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS32 > Page 21 / page 21 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 43 RFQX: RFQX-CVS32-0137 | Although this behavior does not alter the requirements put on the server, it is worth to point out that since the server will reuse the TAG received in the request for several responses, the server has to “remember” the TAG from the request. | CVS32.pdf | IT / backend | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page Figure 11 – Example of a multi-response transaction / page 21 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 44 RFQX: RFQX-CVS32-0138 | Figure 12Figure 12 illustrates error- and state handling in the client’s security sub-layer. | CVS32.pdf | Cybersecurity | Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page 3.3.2 Client’s Behaviour / page 21 Pre-analysis Source classifies this as Information (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 78 RFQX: RFQX-CVS32-0139 | The client shall update its state, (increment PREQARC by one (1), if and only if it can successfully authenticate/encrypt the SDT request (“C2”). | CVS32.pdf | Cybersecurity | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 21 / page 21 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Unverified security control could leave a residual risk in the cybersecurity case. |
| SDT_REQ 79 RFQX: RFQX-CVS32-0140 | At reception of an SDT response, if the client is unauthenticated, the client shall discard the | CVS32.pdf | System | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS32 > Page 22 / page 22 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 80 RFQX: RFQX-CVS32-0141 | At reception of an SDT response, if the request is too short or otherwise malformed, the client shall discard the response. | CVS32.pdf | System | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS32 > Page 22 / page 22 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 81 RFQX: RFQX-CVS32-0142 | At reception of an SDT response, if ANTIREPLAYCNT ≤ PRESARC, the client shall discard the | CVS32.pdf | System | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS32 > Page 22 / page 22 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 82 RFQX: RFQX-CVS32-0143 | At reception of an SDT response, if SIGENCRYPT is not supported, the client shall discard the | CVS32.pdf | System | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS32 > Page 23 / page 23 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 83 RFQX: RFQX-CVS32-0144 | At reception of an SDT response, if APAR is in conflict with SIGENCRYPT, the client shall discard the response. | CVS32.pdf | System | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS32 > Page 23 / page 23 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 84 RFQX: RFQX-CVS32-0145 | At reception of an SDT response, if SIGLEN is in conflict with SIGENCRYPT, the client shall discard the response. | CVS32.pdf | System | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS32 > Page 23 / page 23 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 85 RFQX: RFQX-CVS32-0146 | At reception of an SDT response, if the client fails to verify/decrypt the response, the client shall discard the response. | CVS32.pdf | System | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. | Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS32 > Page 23 / page 23 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer approves the proposed implementation method and responsibility allocation. Engineering notes Validate assumption with customer; complete mapping; implement. Risk / impact Limited; standard implementation and verification risk. |
| SDT_REQ 86 RFQX: RFQX-CVS32-0147 | 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”). | CVS32.pdf | IT / backend | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 23 / page 23 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_INFO 45 RFQX: RFQX-CVS32-0148 | This means that if the client fails to verify/decrypt the SDT response, the client’s state remains unchanged, i.e. | CVS32.pdf | System | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS32 > Page 23 / page 23 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 46 RFQX: RFQX-CVS32-0149 | Messages can get lost going from client to server, or vice versa. | CVS32.pdf | IT / backend | Source classifies this as Information (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page 3.3.2.1 Lost and Repeated SDT Messages / page 23 Pre-analysis Source classifies this as Information (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 47 RFQX: RFQX-CVS32-0150 | Note that busyRepeatRequest, NRC 0x21 (BRR), can be sent in an SDT negative response, or, encapsulated in an SDT positive response. | CVS32.pdf | Interface | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS32 > Page 23 / page 23 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 87 RFQX: RFQX-CVS32-0151 | 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. | CVS32.pdf | IT / backend | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | 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. | Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. | SECURITY DECISION OPEN | Low | Analysis detailsSource section/page CVS32 > Page 23 / page 23 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Engineering notes Agree responsibility split (DIA) for the non-ECU portion. Risk / impact Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. |
| SDT_REQ 7 RFQX: RFQX-CVS32-0152 | . | CVS32.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page or • construct a new SDT request, refer to / page 23 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 48 RFQX: RFQX-CVS32-0153 | A negative UDS response BRR encapsulated in a positive SDT response can of course never result in the resending of an old SDT request. | CVS32.pdf | Interface | Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS32 > Page 23 / page 23 Pre-analysis Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 7 RFQX: RFQX-CVS32-0154 | Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page Updated / page 28 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 14 RFQX: RFQX-CVS32-0155 | Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page Updated / page 28 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 15 RFQX: RFQX-CVS32-0156 | Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page Updated / page 28 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 22 RFQX: RFQX-CVS32-0157 | Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page Updated / page 28 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 25 RFQX: RFQX-CVS32-0158 | Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page Updated / page 28 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 7 RFQX: RFQX-CVS32-0159 | Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS32 > Page 28 / page 28 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 14 RFQX: RFQX-CVS32-0160 | Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS32 > Page 28 / page 28 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 15 RFQX: RFQX-CVS32-0161 | Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS32 > Page 28 / page 28 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 17 RFQX: RFQX-CVS32-0162 | Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS32 > Page 28 / page 28 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 22 RFQX: RFQX-CVS32-0163 | Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS32 > Page 28 / page 28 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 25 RFQX: RFQX-CVS32-0164 | Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS32 > Page 28 / page 28 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 49 RFQX: RFQX-CVS32-0165 | SDT_AES_SIV_CMAC_256 and SDT_CMAC_128 was deprecated and replaced with SDT_AEAD_CHACHA20_POLY1305 and SDT_POLY1305. | CVS32.pdf | System | ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | None | Analysis detailsSource section/page CVS32 > Page 28 / page 28 Pre-analysis ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 13 RFQX: RFQX-CVS32-0166 | (new cipher-schemes) Updated Table 2 (new cipher-schemes) Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS32 > Page 28 / page 28 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 17 RFQX: RFQX-CVS32-0167 | (new cipher-schemes) Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS32 > Page 28 / page 28 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 16 RFQX: RFQX-CVS32-0168 | (new cipher-schemes) Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 28 / page 28 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 20 RFQX: RFQX-CVS32-0169 | (new cipher-schemes) Updated Figure 4 (new cipher-schemes) Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS32 > Page 28 / page 28 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 21 RFQX: RFQX-CVS32-0170 | (new cipher-schemes) Updated 3.2.2 heading (new cipher-schemes) Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS32 > Page 28 / page 28 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 24 RFQX: RFQX-CVS32-0171 | (new cipher-schemes) Updated Figure 5 annotation (new cipher-schemes) Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS32 > Page 28 / page 28 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 31 RFQX: RFQX-CVS32-0172 | (new cipher-schemes) Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 28 / page 28 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 34 RFQX: RFQX-CVS32-0173 | (new cipher-schemes) Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 28 / page 28 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 37 RFQX: RFQX-CVS32-0174 | (new cipher-schemes) Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 28 / page 28 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 38 RFQX: RFQX-CVS32-0175 | (new cipher-schemes) Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 28 / page 28 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 39 RFQX: RFQX-CVS32-0176 | (new cipher-schemes) Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 28 / page 28 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 41 RFQX: RFQX-CVS32-0177 | (new cipher-schemes) Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 28 / page 28 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 42 RFQX: RFQX-CVS32-0178 | (new cipher-schemes) Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 28 / page 28 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 43 RFQX: RFQX-CVS32-0179 | (new cipher-schemes) Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 28 / page 28 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 44 RFQX: RFQX-CVS32-0180 | (new cipher-schemes) Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 28 / page 28 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 48 RFQX: RFQX-CVS32-0181 | (new cipher-schemes) Updated Figure 6 (new cipher-schemes) | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 28 / page 28 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 27 RFQX: RFQX-CVS32-0182 | (new cipher-schemes) Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS32 > Page 29 / page 29 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 30 RFQX: RFQX-CVS32-0183 | (new cipher-schemes) Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS32 > Page 29 / page 29 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 49 RFQX: RFQX-CVS32-0184 | (new cipher-schemes) Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 29 / page 29 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 50 RFQX: RFQX-CVS32-0185 | (new cipher-schemes) Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 29 / page 29 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 51 RFQX: RFQX-CVS32-0186 | (new cipher-schemes) Added | CVS32.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS32 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 49 RFQX: RFQX-CVS32-0187 | (new cipher-schemes) Added Figure 7 (new cipher-schemes) Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | None | Analysis detailsSource section/page CVS32 > Page 29 / page 29 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 52 RFQX: RFQX-CVS32-0188 | (new cipher-schemes) Added | CVS32.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS32 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 89 RFQX: RFQX-CVS32-0189 | (new cipher-schemes) Added | CVS32.pdf | System | Source classifies this as Requirement (non-binding). | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | ASSUMPTION BASED | Low | Analysis detailsSource section/page CVS32 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 90 RFQX: RFQX-CVS32-0190 | (new cipher-schemes) Added | CVS32.pdf | System | Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | ASSUMPTION BASED | Medium | Analysis detailsSource section/page CVS32 > Page 29 / page 29 Pre-analysis Source classifies this as Requirement (non-binding). Linked source table/diagram context was considered for interpretation. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 91 RFQX: RFQX-CVS32-0191 | (new cipher-schemes) Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 29 / page 29 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 54 RFQX: RFQX-CVS32-0192 | (new cipher-schemes) Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 29 / page 29 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 57 RFQX: RFQX-CVS32-0193 | (new cipher-schemes) Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 29 / page 29 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 58 RFQX: RFQX-CVS32-0194 | (new cipher-schemes) Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 29 / page 29 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 59 RFQX: RFQX-CVS32-0195 | (new cipher-schemes) Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 29 / page 29 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 60 RFQX: RFQX-CVS32-0196 | (new cipher-schemes) Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 29 / page 29 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 61 RFQX: RFQX-CVS32-0197 | (new cipher-schemes) Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 29 / page 29 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 62 RFQX: RFQX-CVS32-0198 | (new cipher-schemes) Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 29 / page 29 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 63 RFQX: RFQX-CVS32-0199 | (new cipher-schemes) Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 29 / page 29 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 66 RFQX: RFQX-CVS32-0200 | (new cipher-schemes) Updated Figure 8 (new cipher-schemes) Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 29 / page 29 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_INFO 33 RFQX: RFQX-CVS32-0201 | (new cipher-schemes) Updated | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | Medium | Analysis detailsSource section/page CVS32 > Page 29 / page 29 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 88 RFQX: RFQX-CVS32-0202 | (new cipher-schemes) Updated 4 References (new cipher-schemes) Updated Annex A (new cipher-schemes) Updated test vectors to be correct after change from SHA-256 to SHA-512 Exhausted PRESARC server behavior. | CVS32.pdf | IT / backend | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Capture as background context in the concept; no work product committed. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page CVS32 > Page 29 / page 29 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |
| SDT_REQ 88 RFQX: RFQX-CVS32-0203 | and updated Figure 9.) 2025-08 1 This standard has been revised and is valid for continued use. | CVS32.pdf | System | Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Related source tables/diagrams are treated as interpretation context, not separate customer IDs. | Capture as background context in the concept; no work product committed. Review linked table/diagram context before final design and verification. | SECURITY DECISION OPEN | High | Analysis detailsSource section/page (added / page 29 Pre-analysis Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Assumptions Customer confirms it is binding. Engineering notes No action unless the customer confirms it is binding. Risk / impact Misinterpreted requirement could drive wrong design and late change cost. |