Requirement Review Register
Product and cybersecurity architecture understanding package generated from Markdown-derived requirements.
Executive Takeaway
The requirement review register is the working control surface for RFQX. It shows each Markdown-derived requirement, the supplier position, proposal wording, traceability, and remaining customer decision dependency.
- Accepted and assumption-based rows can support proposal planning.
- Partial and clarification rows must stay conditional until the customer confirms responsibility and scope.
- Informational rows remain evidence context unless made binding by the customer.
Filter & Search
Requirements
This table is horizontally scrollable. Use the bottom scrollbar to view all columns.
| ID | Requirement / Expectation | Supplier Position | Proposal / Decision | Security Feature | Traceability | Status | Details |
|---|---|---|---|---|---|---|---|
| REQ-AUTO-00001 | The cybersecurity concept shall describe the scope of the risk analysis, risks that were identified during the risk analysis, cybe rsecurity goals, cybersecurity requirements, mitigation strategies, validation, and verification strategies, etc.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Validate assumption with customer; complete mapping; implement. | Cybersecurity requirement handling | Feature / interface: Cybersecurity requirement handling; Security evidence and traceability / OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface SSR: SSR-CON-001 | High Proposal Ready Open point: - | DetailsFull requirement text The cybersecurity concept shall describe the scope of the risk analysis, risks that were identified during the risk analysis, cybe rsecurity goals, cybersecurity requirements, mitigation strategies, validation, and verification strategies, etc. Engineering expectation Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Cybersecurity requirement handling; Security evidence and traceability | Security capability: Cybersecurity requirement handling | Interface: OEM/Customer Review Interface | Architecture: Security Services; OEM/Customer Review Interface | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-CON-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 3 · page 3 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0001 | Cybersecurity methods and strategiesThe supplier shall provide documentation describing their strategies and methods for working with embedded systems cybersecurity.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | Cybersecurity requirement handling | Feature / interface: Cybersecurity requirement handling; Security evidence and traceability / OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface SSR: SSR-CON-001 | High Proposal Ready Open point: - | DetailsFull requirement text Cybersecurity methods and strategies REQ_SEC_0001 The supplier shall provide documentation describing their strategies and methods for working with embedded systems cybersecurity. Engineering expectation Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Cybersecurity requirement handling; Security evidence and traceability | Security capability: Cybersecurity requirement handling | Interface: OEM/Customer Review Interface | Architecture: Security Services; OEM/Customer Review Interface | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-CON-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 5 · page 5 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0002 | Risk assessmentThe supplier shall perform risk assessment based on a threat and vulnerability analysis for each release, including any vehicle manufacturer-specific adaptations.Expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Accept with Assumption | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation.Decision: Validate assumption with customer; complete mapping; implement. | Vulnerability management | Feature / interface: Vulnerability management / OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface SSR: SSR-VIH-001 | High Proposal Ready Open point: - | DetailsFull requirement text Risk assessment REQ_SEC_0002 The supplier shall perform risk assessment based on a threat and vulnerability analysis for each release, including any vehicle manufacturer-specific adaptations. Engineering expectation Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Supplier proposal Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Vulnerability management | Security capability: Vulnerability management | Interface: OEM/Customer Review Interface | Architecture: Security Services; OEM/Customer Review Interface | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-VIH-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 5 · page 5 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00004 | Method and scope shall be proposed to and approved by the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text Method and scope shall be proposed to and approved by the vehicle manufacturer. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 5 · page 5 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00005 | Documentation on the method and results shall be provided to the vehicle manufacturer.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Security evidence and traceability / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text Documentation on the method and results shall be provided to the vehicle manufacturer. Engineering expectation Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 5 · page 5 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00006 | Note: The vehicle manufacturer and supplier shall collaboratively define the context of the system or function to enable the supplier performing the risk assessment.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Needs Customer Clarification | Needs customer clarification. The requirement implies customer-owned infrastructure, approval, or a responsibility split that is not yet available.Decision: Send linked open point to the customer for decision. | None | Feature / interface: Application software behavior / OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface SSR: None | Unknown Reviewed Internally Open point: OP-011 | DetailsFull requirement text Note: The vehicle manufacturer and supplier shall collaboratively define the context of the system or function to enable the supplier performing the risk assessment. Engineering expectation Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Supplier proposal Needs customer clarification. The requirement implies customer-owned infrastructure, approval, or a responsibility split that is not yet available. Rationale Flagged customer_clarification_needed=yes during extraction. Implementation approach Hold implementation; raise an open point and a clarification question. Acceptance condition Customer answers the linked open point. Customer feedback - Customer decision - Customer clarification / open point Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline. Traceability Feature: Application software behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Application Software; OEM/Customer Review Interface | Work product: System/architecture design | SSR: None Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 5 · page 5 Estimation / resource / tool / IT / hardware impact Effort Unknown, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Scope and effort cannot be frozen; estimation carries an open assumption and downstream design may rework. Next action Send linked open point to the customer for decision. |
| REQ_SEC_0003 | Cybersecurity conceptThe supplier shall describe the cybersecurity concept and how it is implemented in hardware and software respectively.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Validate assumption with customer; complete mapping; implement. | Cybersecurity requirement handling | Feature / interface: Cybersecurity requirement handling / OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface SSR: SSR-CON-001 | High Proposal Ready Open point: - | DetailsFull requirement text Cybersecurity concept REQ_SEC_0003 The supplier shall describe the cybersecurity concept and how it is implemented in hardware and software respectively. Engineering expectation Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Cybersecurity requirement handling | Security capability: Cybersecurity requirement handling | Interface: OEM/Customer Review Interface | Architecture: Security Services; OEM/Customer Review Interface | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-CON-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 5 · page 5 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0022 | Marcus Lindner EPXC Published 6(16)All risks identified in cybersecurity risk analyses shall be evaluated.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | Cybersecurity requirement handling | Feature / interface: Cybersecurity requirement handling Architecture: Security Services SSR: SSR-CON-001 | High Proposal Ready Open point: - | DetailsFull requirement text Marcus Lindner EPXC Published 6(16) REQ_SEC_0022 All risks identified in cybersecurity risk analyses shall be evaluated. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Cybersecurity requirement handling | Security capability: Cybersecurity requirement handling | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-CON-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00009 | For each risk identified in the cybersecurity risk analyses, a risk treatment decision shall be made to avoid, reduce, share, or retain the risk.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Validate assumption with customer; complete mapping; implement. | Cybersecurity requirement handling | Feature / interface: Cybersecurity requirement handling Architecture: Security Services SSR: SSR-CON-001 | High Proposal Ready Open point: - | DetailsFull requirement text For each risk identified in the cybersecurity risk analyses, a risk treatment decision shall be made to avoid, reduce, share, or retain the risk. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Cybersecurity requirement handling | Security capability: Cybersecurity requirement handling | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-CON-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0023 | Cybersecurity controls shall sufficiently reduce the risk.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | Cybersecurity requirement handling | Feature / interface: Cybersecurity requirement handling Architecture: Security Services SSR: SSR-CON-001 | High Proposal Ready Open point: - | DetailsFull requirement text REQ_SEC_0023 Cybersecurity controls shall sufficiently reduce the risk. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Cybersecurity requirement handling | Security capability: Cybersecurity requirement handling | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-CON-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00011 | It shall be possible to verify which cybersecurity controls were derived from which requirements.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | Cybersecurity requirement handling | Feature / interface: Cybersecurity requirement handling Architecture: Security Services SSR: SSR-CON-001 | High Proposal Ready Open point: - | DetailsFull requirement text It shall be possible to verify which cybersecurity controls were derived from which requirements. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Cybersecurity requirement handling | Security capability: Cybersecurity requirement handling | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-CON-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0024 | The cybersecurity concept of the supplier shall contain a documentation of the accepted residual risk and be agreed with the vehicle manufacturer.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Validate assumption with customer; complete mapping; implement. | Cybersecurity requirement handling | Feature / interface: Cybersecurity requirement handling; Security evidence and traceability / OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface SSR: SSR-CON-001 | High Proposal Ready Open point: - | DetailsFull requirement text REQ_SEC_0024 The cybersecurity concept of the supplier shall contain a documentation of the accepted residual risk and be agreed with the vehicle manufacturer. Engineering expectation Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Cybersecurity requirement handling; Security evidence and traceability | Security capability: Cybersecurity requirement handling | Interface: OEM/Customer Review Interface | Architecture: Security Services; OEM/Customer Review Interface | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-CON-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0004 | Verification and validationThe supplier shall provide documentation of the verification and validation methods of cybersecurity features.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | Cybersecurity requirement handling | Feature / interface: Cybersecurity requirement handling; Security evidence and traceability / OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface SSR: SSR-CON-001 | High Proposal Ready Open point: - | DetailsFull requirement text Verification and validation REQ_SEC_0004 The supplier shall provide documentation of the verification and validation methods of cybersecurity features. Engineering expectation Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Cybersecurity requirement handling; Security evidence and traceability | Security capability: Cybersecurity requirement handling | Interface: OEM/Customer Review Interface | Architecture: Security Services; OEM/Customer Review Interface | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-CON-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0005 | The supplier shall provide test reports detailing the results from the verification and validation of cybersecurity features.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | Cybersecurity requirement handling | Feature / interface: Cybersecurity requirement handling; Security evidence and traceability / OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface SSR: SSR-CON-001 | High Proposal Ready Open point: - | DetailsFull requirement text REQ_SEC_0005 The supplier shall provide test reports detailing the results from the verification and validation of cybersecurity features. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Cybersecurity requirement handling; Security evidence and traceability | Security capability: Cybersecurity requirement handling | Interface: OEM/Customer Review Interface | Architecture: Security Services; OEM/Customer Review Interface | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-CON-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0040 | The vehicle manufacturer reserves the right to perform penetration testing on the ECU to identify potential vulnerabilities.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text REQ_SEC_0040 The vehicle manufacturer reserves the right to perform penetration testing on the ECU to identify potential vulnerabilities. Engineering expectation Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Medium, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ_SEC_0007 | DocumentationAn inventory of software and protocols, including their versions, shall be provided by the supplier.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior; Security evidence and traceability / OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text Documentation REQ_SEC_0007 An inventory of software and protocols, including their versions, shall be provided by the supplier. Engineering expectation Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Application Software; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-007 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0025 | Marcus Lindner EPXC Published 7(16)A BOM containing part numbers and versions of hardware components used in the product shall be provided by the supplier.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Hardware platform support / OEM/Customer Review Interface Architecture: Hardware Platform; OEM/Customer Review Interface SSR: SSR-COM-001 | High Proposal Ready Open point: - | DetailsFull requirement text Marcus Lindner EPXC Published 7(16) REQ_SEC_0025 A BOM containing part numbers and versions of hardware components used in the product shall be provided by the supplier. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Hardware Platform; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-COM-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 7 · page 7 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0041 | The vehicle manufacturer reserves the right to request documentation and evidence as well as to perform or order a compliance audit to determine whether the listed requirements are fulfilled.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: Security evidence and traceability Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text REQ_SEC_0041 The vehicle manufacturer reserves the right to request documentation and evidence as well as to perform or order a compliance audit to determine whether the listed requirements are fulfilled. Engineering expectation Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Security evidence and traceability | Security capability: None | Interface: None | Architecture: None | Work product: DIA / cybersecurity case | SSR: None Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 7 · page 7 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ_SEC_0042 | The vehicle manufacturer and the supplier shall set up a cybersecurity DIA to agree on the responsibilities for the distributed cybersecurity activities.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Validate assumption with customer; complete mapping; implement. | Cybersecurity requirement handling | Feature / interface: Cybersecurity requirement handling / OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface SSR: SSR-CON-001 | High Proposal Ready Open point: - | DetailsFull requirement text REQ_SEC_0042 The vehicle manufacturer and the supplier shall set up a cybersecurity DIA to agree on the responsibilities for the distributed cybersecurity activities. Engineering expectation Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Cybersecurity requirement handling | Security capability: Cybersecurity requirement handling | Interface: OEM/Customer Review Interface | Architecture: Security Services; OEM/Customer Review Interface | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-CON-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 7 · page 7 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0008 | Software securityThe ECU shall be able to verify integrity and authenticity of a vehicle manufacturer-specified set of data stored within the ECU.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | Authentication | Feature / interface: Authentication / OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface SSR: SSR-DAI-001 | High Proposal Ready Open point: - | DetailsFull requirement text Software security REQ_SEC_0008 The ECU shall be able to verify integrity and authenticity of a vehicle manufacturer-specified set of data stored within the ECU. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Authentication | Security capability: Authentication | Interface: OEM/Customer Review Interface | Architecture: Security Services; OEM/Customer Review Interface | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-DAI-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 7 · page 7 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00021 | Methods shall be proposed to and approved by the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text Methods shall be proposed to and approved by the vehicle manufacturer. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 7 · page 7 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ_SEC_0009 | Security architectureThe supplier shall apply methods for isolation of software/hardware components and data to reduce the effect in case of a cybersecurity breach.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | Cybersecurity requirement handling | Feature / interface: Cybersecurity requirement handling / OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface SSR: SSR-CON-001 | High Proposal Ready Open point: - | DetailsFull requirement text Security architecture REQ_SEC_0009 The supplier shall apply methods for isolation of software/hardware components and data to reduce the effect in case of a cybersecurity breach. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Cybersecurity requirement handling | Security capability: Cybersecurity requirement handling | Interface: OEM/Customer Review Interface | Architecture: Security Services; OEM/Customer Review Interface | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-CON-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 7 · page 7 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0020 | Cryptographic librariesSelection of cryptographic methods and their use shall be agreed upon between the vehicle manufacturer and the supplier.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-001 | High Proposal Ready Open point: - | DetailsFull requirement text Cryptographic libraries REQ_SEC_0020 Selection of cryptographic methods and their use shall be agreed upon between the vehicle manufacturer and the supplier. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 7 · page 7 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0010 | ServicesAll network services implemented in the ECU shall undergo hardening.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Hardware platform support Architecture: Hardware Platform SSR: SSR-PROD-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text Services REQ_SEC_0010 All network services implemented in the ECU shall undergo hardening. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-PROD-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0011 | The ECU shall only expose network and communication services that have been agreed upon with the vehicle manufacturer.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Hardware platform support / OEM/Customer Review Interface Architecture: Hardware Platform; OEM/Customer Review Interface SSR: SSR-COM-001 | Low Proposal Ready Open point: - | DetailsFull requirement text REQ_SEC_0011 The ECU shall only expose network and communication services that have been agreed upon with the vehicle manufacturer. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Hardware Platform; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-COM-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0012 | InterfacesCommunication interfaces shall use boundary controls such as ingress/egress filtering.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-001 | High Proposal Ready Open point: - | DetailsFull requirement text Interfaces REQ_SEC_0012 Communication interfaces shall use boundary controls such as ingress/egress filtering. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0013 | Communication boundary controls shall be configurable by the vehicle manufacturer.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_SEC_0013 Communication boundary controls shall be configurable by the vehicle manufacturer. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00028 | Methods shall be proposed and approved by the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text Methods shall be proposed and approved by the vehicle manufacturer. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ_SEC_0014 | Any interfaces used for development purposes shall be removed or disabled in series production.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-001 | High Proposal Ready Open point: - | DetailsFull requirement text REQ_SEC_0014 Any interfaces used for development purposes shall be removed or disabled in series production. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00030 | The details shall be agreed upon between the vehicle manufacturer and the supplier.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text The details shall be agreed upon between the vehicle manufacturer and the supplier. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0026 | Only hardware interfaces and protocols specified by the vehicle manufacturer shall be available in series production.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Hardware platform support / OEM/Customer Review Interface Architecture: Hardware Platform; OEM/Customer Review Interface SSR: SSR-COM-001 | Low Proposal Ready Open point: OP-008 | DetailsFull requirement text REQ_SEC_0026 Only hardware interfaces and protocols specified by the vehicle manufacturer shall be available in series production. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-008 Traceability Feature: Hardware platform support | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Hardware Platform; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-COM-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test High Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_SEC_0027 | Information securityIt shall be possible for the vehicle manufacturer to securely inject data into the product in accordance with the specification provided by the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | Cybersecurity requirement handling | Feature / interface: Cybersecurity requirement handling / OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface SSR: SSR-CON-001 | High Proposal Ready Open point: - | DetailsFull requirement text Information security REQ_SEC_0027 It shall be possible for the vehicle manufacturer to securely inject data into the product in accordance with the specification provided by the vehicle manufacturer. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Cybersecurity requirement handling | Security capability: Cybersecurity requirement handling | Interface: OEM/Customer Review Interface | Architecture: Security Services; OEM/Customer Review Interface | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-CON-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0028 | Marcus Lindner EPXC Published 9(16)Data specified by the vehicle manufacturer shall be protected from manipulations.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text Marcus Lindner EPXC Published 9(16) REQ_SEC_0028 Data specified by the vehicle manufacturer shall be protected from manipulations. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ_SEC_0029 | Data specified by the vehicle manufacturer shall be protected from disclosure.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_SEC_0029 Data specified by the vehicle manufacturer shall be protected from disclosure. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ_SEC_0006 | Intellectual property of the vehicle manufacturer shall be protected from disclosure.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_SEC_0006 Intellectual property of the vehicle manufacturer shall be protected from disclosure. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ_SEC_0016 | Key managementIt shall be possible for the vehicle manufacturer to securely inject key material and other data used for cybersecurity controls into the ECU according to the specification of the vehicle manufacturer.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Key management | Feature / interface: Key management / OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface SSR: SSR-KEY-001 | High Proposal Ready Open point: OP-003 | DetailsFull requirement text Key management REQ_SEC_0016 It shall be possible for the vehicle manufacturer to securely inject key material and other data used for cybersecurity controls into the ECU according to the specification of the vehicle manufacturer. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-003 Traceability Feature: Key management | Security capability: Key management | Interface: OEM/Customer Review Interface | Architecture: Security Services; OEM/Customer Review Interface | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-KEY-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT Low, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_SEC_0019 | Secrets, public keys and other data used for cybersecurity controls in production vehicle systems shall be different from those used in pre-production phases.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | Key management | Feature / interface: Key management Architecture: Security Services SSR: SSR-KEY-001 | High Proposal Ready Open point: - | DetailsFull requirement text REQ_SEC_0019 Secrets, public keys and other data used for cybersecurity controls in production vehicle systems shall be different from those used in pre-production phases. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Key management | Security capability: Key management | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-KEY-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0021 | ECUs shall only contain the secrets agreed between the vehicle manufacturer and the supplier.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-001 | Low Proposal Ready Open point: - | DetailsFull requirement text REQ_SEC_0021 ECUs shall only contain the secrets agreed between the vehicle manufacturer and the supplier. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0015 | ECUs shall conform to the harmonized Security Access specification [1] provided by the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | Cybersecurity requirement handling | Feature / interface: Cybersecurity requirement handling / OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface SSR: SSR-CON-001 | High Proposal Ready Open point: - | DetailsFull requirement text REQ_SEC_0015 ECUs shall conform to the harmonized Security Access specification [1] provided by the vehicle manufacturer. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Cybersecurity requirement handling | Security capability: Cybersecurity requirement handling | Interface: OEM/Customer Review Interface | Architecture: Security Services; OEM/Customer Review Interface | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-CON-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0043 | Security updatesIt shall be possible to update the software of the ECU.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | Cybersecurity requirement handling | Feature / interface: Cybersecurity requirement handling Architecture: Security Services SSR: SSR-CON-001 | High Proposal Ready Open point: - | DetailsFull requirement text Security updates REQ_SEC_0043 It shall be possible to update the software of the ECU. Engineering expectation Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Cybersecurity requirement handling | Security capability: Cybersecurity requirement handling | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-CON-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0030 | Marcus Lindner EPXC Published 10(16)The supplier shall inform the vehicle manufacturer if any cybersecurity patches are available.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation.Decision: Validate assumption with customer; complete mapping; implement. | Cybersecurity requirement handling | Feature / interface: Cybersecurity requirement handling / OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface SSR: SSR-CON-001 | High Proposal Ready Open point: - | DetailsFull requirement text Marcus Lindner EPXC Published 10(16) REQ_SEC_0030 The supplier shall inform the vehicle manufacturer if any cybersecurity patches are available. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Cybersecurity requirement handling | Security capability: Cybersecurity requirement handling | Interface: OEM/Customer Review Interface | Architecture: Security Services; OEM/Customer Review Interface | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-CON-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0044 | Incident managementAn incident response process shall be proposed to and approved by the vehicle manufacturer.Expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Accept with Assumption | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: Compliance Process; OEM/Customer Review Interface SSR: SSR-VIH-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text Incident management REQ_SEC_0044 An incident response process shall be proposed to and approved by the vehicle manufacturer. Engineering expectation Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Supplier proposal Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Compliance Process; OEM/Customer Review Interface | Work product: DIA / cybersecurity case | SSR: SSR-VIH-002 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0045 | In case of cybersecurity incidents, the incident response process shall be used.Expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Accept with Assumption | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation.Decision: Validate assumption with customer; complete mapping; implement. | Incident response | Feature / interface: Incident response Architecture: Security Services SSR: SSR-VIH-003 | High Proposal Ready Open point: - | DetailsFull requirement text REQ_SEC_0045 In case of cybersecurity incidents, the incident response process shall be used. Engineering expectation Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Supplier proposal Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Incident response | Security capability: Incident response | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-VIH-003 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0046 | The incident response process shall be maintained for the entire product lifetime.Expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Accept with Assumption | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-VIH-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_SEC_0046 The incident response process shall be maintained for the entire product lifetime. Engineering expectation Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Supplier proposal Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-VIH-002 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0032 | The incident response process shall ensure that risk is managed in coordination with the vehicle manufacturer.Expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Accept with Assumption | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: Compliance Process; OEM/Customer Review Interface SSR: SSR-VIH-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_SEC_0032 The incident response process shall ensure that risk is managed in coordination with the vehicle manufacturer. Engineering expectation Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Supplier proposal Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Compliance Process; OEM/Customer Review Interface | Work product: DIA / cybersecurity case | SSR: SSR-VIH-002 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0033 | Vulnerability managementAny vulnerabilities that are identified during product lifecycle shall be promptly communicated to the vehicle manufacturer.Expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Accept with Assumption | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-VIH-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text Vulnerability management REQ_SEC_0033 Any vulnerabilities that are identified during product lifecycle shall be promptly communicated to the vehicle manufacturer. Engineering expectation Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Supplier proposal Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-VIH-004 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00047 | The report shall include information needed to identify the affected vehicles/products.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text The report shall include information needed to identify the affected vehicles/products. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00048 | Methods including the stipulation of a reasonable notification time shall be proposed to and approved by the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text Methods including the stipulation of a reasonable notification time shall be proposed to and approved by the vehicle manufacturer. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ_SEC_0034 | Following each identified and reported vulnerability, the supplier and vehicle manufacturer shall agree on an initial response to the vulnerability.Expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Partially Accept | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-VIH-004 | Medium Proposal Ready Open point: OP-006 | DetailsFull requirement text REQ_SEC_0034 Following each identified and reported vulnerability, the supplier and vehicle manufacturer shall agree on an initial response to the vulnerability. Engineering expectation Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Supplier proposal Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-006 Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-VIH-004 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_SEC_0035 | Marcus Lindner EPXC Published 11(16)Within adequate time after the initial vulnerability report, the supplier shall provide more information about the identified vulnerability.Expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Accept with Assumption | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-VIH-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text Marcus Lindner EPXC Published 11(16) REQ_SEC_0035 Within adequate time after the initial vulnerability report, the supplier shall provide more information about the identified vulnerability. Engineering expectation Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Supplier proposal Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-VIH-004 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00051 | The information shall contain • the version(s) of affected hardware or software components, • nature of the vulnerability, • description of the affected cybersecurity goal, • technical conditions to exploit the vulnerability, • impact of the exploitation and • possibilities to remove the vulnerability.Expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Accept with Assumption | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation.Decision: Validate assumption with customer; complete mapping; implement. | Vulnerability management | Feature / interface: Vulnerability management Architecture: Security Services SSR: SSR-VIH-001 | High Proposal Ready Open point: - | DetailsFull requirement text The information shall contain • the version(s) of affected hardware or software components, • nature of the vulnerability, • description of the affected cybersecurity goal, • technical conditions to exploit the vulnerability, • impact of the exploitation and • possibilities to remove the vulnerability. Engineering expectation Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Supplier proposal Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Vulnerability management | Security capability: Vulnerability management | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-VIH-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00052 | Methods including the stipulation of a reasonable reporting time shall be proposed to and approved by the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text Methods including the stipulation of a reasonable reporting time shall be proposed to and approved by the vehicle manufacturer. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ_SEC_0036 | The supplier shall have a method for monitoring available vulnerability databases for vulnerabilities that can affect the delivered product.Expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Accept with Assumption | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces / External Interfaces; OEM/Customer Review Interface Architecture: External Interfaces; OEM/Customer Review Interface SSR: SSR-VIH-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_SEC_0036 The supplier shall have a method for monitoring available vulnerability databases for vulnerabilities that can affect the delivered product. Engineering expectation Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Supplier proposal Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces | Security capability: None | Interface: External Interfaces; OEM/Customer Review Interface | Architecture: External Interfaces; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-VIH-005 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0037 | Identified vulnerabilities shall be considered in all current development projects or projects under field monitoring.Expectation: Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. | Accept with Assumption | Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_SEC_0037 Identified vulnerabilities shall be considered in all current development projects or projects under field monitoring. Engineering expectation Lifecycle security is expected to define ownership for monitoring, vulnerability handling, incident response, and mitigation evidence. Supplier proposal Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0047 | Product lifecycleAn ECU returned from field shall allow for field-return analysis.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Hardware platform support Architecture: Hardware Platform SSR: SSR-HW-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text Product lifecycle REQ_SEC_0047 An ECU returned from field shall allow for field-return analysis. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-HW-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ_SEC_0048 | Field-return analysis secrets shall not be operational in the field.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-001 | Low Proposal Ready Open point: - | DetailsFull requirement text REQ_SEC_0048 Field-return analysis secrets shall not be operational in the field. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0049 | An ECU enabled for field-return analysis shall not be possible to use as a spare part.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Hardware platform support Architecture: Hardware Platform SSR: SSR-LIFE-001 | Low Proposal Ready Open point: - | DetailsFull requirement text REQ_SEC_0049 An ECU enabled for field-return analysis shall not be possible to use as a spare part. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-LIFE-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ_SEC_0050 | Marcus Lindner EPXC Published 12(16)All secrets specified by the vehicle manufacturer shall be protected throughout the lifecycle of the ECU.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Hardware platform support / OEM/Customer Review Interface Architecture: Hardware Platform; OEM/Customer Review Interface SSR: SSR-COM-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text Marcus Lindner EPXC Published 12(16) REQ_SEC_0050 All secrets specified by the vehicle manufacturer shall be protected throughout the lifecycle of the ECU. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Hardware Platform; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-COM-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test High Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00059 | End-of-life and decommissioning shall be specifically considered.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-LIFE-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text End-of-life and decommissioning shall be specifically considered. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-LIFE-002 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00060 | Notes: a) It shall not be possible for a third party to reuse an ECU without system support from the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Hardware platform support / OEM/Customer Review Interface Architecture: Hardware Platform; OEM/Customer Review Interface SSR: SSR-HW-001 | Low Proposal Ready Open point: - | DetailsFull requirement text Notes: a) It shall not be possible for a third party to reuse an ECU without system support from the vehicle manufacturer. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Hardware Platform; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-HW-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00061 | b) Decommissioning of an ECU shall not have the potential of causing unacceptable risk to the road user or the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Hardware platform support / OEM/Customer Review Interface Architecture: Hardware Platform; OEM/Customer Review Interface SSR: SSR-LIFE-001 | Low Proposal Ready Open point: - | DetailsFull requirement text b) Decommissioning of an ECU shall not have the potential of causing unacceptable risk to the road user or the vehicle manufacturer. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Hardware Platform; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-LIFE-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ_SEC_0051 | LoggingSecurity related events shall be identified and logged.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | Logging and audit trail | Feature / interface: Logging and audit trail Architecture: Security Services SSR: SSR-LOG-001 | High Proposal Ready Open point: - | DetailsFull requirement text Logging REQ_SEC_0051 Security related events shall be identified and logged. Engineering expectation Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Logging and audit trail | Security capability: Logging and audit trail | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-LOG-001 Source evidence converted/markdown-cleaned/1001379436_P10_000_01_RDDM-1140152501-1744.md · 1001379436_P10_000_01_RDDM-1140152501-1744 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00063 | The gearbox itself shall be used in all drivetrains and the ECA shall be common and must be complaint to be put on any driveline setup.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text The gearbox itself shall be used in all drivetrains and the ECA shall be common and must be complaint to be put on any driveline setup. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 3 · page 3 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00064 | P 1 Page 2 General 2.1 The clutch actuator shall be electrically driven.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text P 1 Page 2 General 2.1 The clutch actuator shall be electrically driven. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 4 · page 4 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00065 | 2.2 The actuator is placed outside of the gearbox 2.3 The ECA (Electric Clutch Actuator) must have its own internal ECU for manoeuvring and error handling.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Hardware platform support Architecture: Hardware Platform SSR: SSR-HW-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 2.2 The actuator is placed outside of the gearbox 2.3 The ECA (Electric Clutch Actuator) must have its own internal ECU for manoeuvring and error handling. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-HW-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 4 · page 4 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00066 | 2.4 The actuator will be controlled by a position and speed demand by CAN-bus 2.5 The actuator will be controlled by a position and speed demand by a 1kHz PWM signal on wake up connection 2.6 The ECA units shall be manufactured with marking variants according to the requirements in Scania STD19 (Ref 14.17).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text 2.4 The actuator will be controlled by a position and speed demand by CAN-bus 2.5 The actuator will be controlled by a position and speed demand by a 1kHz PWM signal on wake up connection 2.6 The ECA units shall be manufactured with marking variants according to the requirements in Scania STD19 (Ref 14.17). Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 4 · page 4 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00067 | The variant type shall be based on delivery agreement and Brand involved.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text The variant type shall be based on delivery agreement and Brand involved. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 4 · page 4 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00068 | Common marking requirements that must be fulfilled for each marking variant are: Marking method: MA1 Marking height: 3 mm Date format: YYMMDD A unique serial number A DMC according to Scania STD 4562 (Ref 14.18) that contains the part number and serial number information.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text Common marking requirements that must be fulfilled for each marking variant are: Marking method: MA1 Marking height: 3 mm Date format: YYMMDD A unique serial number A DMC according to Scania STD 4562 (Ref 14.18) that contains the part number and serial number information. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 4 · page 4 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00069 | The marking shall not be visible when the ECA is mounted on a gearbox.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-001 | Low Proposal Ready Open point: - | DetailsFull requirement text The marking shall not be visible when the ECA is mounted on a gearbox. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 4 · page 4 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00070 | The ECA units shall be delivered to the required Traton brand’s production in a position in the pallet where the marking is visible.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text The ECA units shall be delivered to the required Traton brand’s production in a position in the pallet where the marking is visible. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 4 · page 4 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00071 | 4.16) shall be marked according to the requirements in Scania STD19 (Ref 14.17) Tentik, wordmark variant W Part number (9 digits, two spaces in format 12 345 6789) Marking method: CAS Marking height: 2-6 mm.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 4.16) shall be marked according to the requirements in Scania STD19 (Ref 14.17) Tentik, wordmark variant W Part number (9 digits, two spaces in format 12 345 6789) Marking method: CAS Marking height: 2-6 mm. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 5 · page 5 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00072 | Alternative design: CXM or equivalent combination of date dial and date field The rubber cover marking shall not be visible when the ECA is mounted on a gearbox 2.8 The ECA shall be designed with Remanufacturing and/or Refurbishment in mind with possibility of swapping out larger electronic assemblies/components.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-001 | Low Proposal Ready Open point: - | DetailsFull requirement text Alternative design: CXM or equivalent combination of date dial and date field The rubber cover marking shall not be visible when the ECA is mounted on a gearbox 2.8 The ECA shall be designed with Remanufacturing and/or Refurbishment in mind with possibility of swapping out larger electronic assemblies/components. Engineering expectation Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 5 · page 5 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00073 | Details to be agreed with Traton 2.9 Traton shall be invited to participate in electrical and mechanical design reviews.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text Details to be agreed with Traton 2.9 Traton shall be invited to participate in electrical and mechanical design reviews. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 5 · page 5 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00074 | 2.10 Traton requires extensive testing to be performed by the supplier to verify all demands stated in the requirement specification.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 2.10 Traton requires extensive testing to be performed by the supplier to verify all demands stated in the requirement specification. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 5 · page 5 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00075 | 2.11 The mechanics shall also be tested and verified, in an overall durability test as stated in Appendix B etc.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 2.11 The mechanics shall also be tested and verified, in an overall durability test as stated in Appendix B etc. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 5 · page 5 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00076 | 2.12 Traton requires:Documentation of the product, i.e.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Security evidence and traceability / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 2.12 Traton requires: - Documentation of the product, i.e. Engineering expectation Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 5 · page 5 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00077 | Should the PP be fully calculated from the AP-sensor, then this offset should not exist.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Needs Internal Review | Needs internal review. Confirm whether this should-level requirement is in the committed baseline.Decision: Complete internal review of wording and baseline scope. | None | Feature / interface: Hardware platform support Architecture: Hardware Platform SSR: None | Low Reviewed Internally Open point: - | DetailsFull requirement text Should the PP be fully calculated from the AP-sensor, then this offset should not exist. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Needs internal review. Confirm whether this should-level requirement is in the committed baseline. Rationale Non-mandatory wording; baseline inclusion not yet confirmed. Implementation approach Decide baseline inclusion internally, then issue an Accept/Partial position. Acceptance condition Internal baseline decision recorded. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 7 · page 7 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Complete internal review of wording and baseline scope. |
| REQ-AUTO-00078 | P 1 Page 4 Mechanical interface 4.1 The maximum release stroke is 22,4 mm from FCCP 4.2 The total stroke of the actuator shall be 85 mm.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: External interfaces / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | High Proposal Ready Open point: OP-004 | DetailsFull requirement text P 1 Page 4 Mechanical interface 4.1 The maximum release stroke is 22,4 mm from FCCP 4.2 The total stroke of the actuator shall be 85 mm. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-004 Traceability Feature: External interfaces | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00079 | 4.3 The clutch actuator shall be able to reach the extreme positions A and B in with the center of the pushrod end.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 4.3 The clutch actuator shall be able to reach the extreme positions A and B in with the center of the pushrod end. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00080 | P 1 Page 4.4 ECA shall not interfere with any geometry in the 3D envelope 53612101-1 1_RFQ2030.stp except where interference fits or other types of functional contacts are required.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-001 | Low Proposal Ready Open point: - | DetailsFull requirement text P 1 Page 4.4 ECA shall not interfere with any geometry in the 3D envelope 53612101-1 1_RFQ2030.stp except where interference fits or other types of functional contacts are required. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00081 | 4.6 When the ECA is assembled, it shall not be possible to insert an object larger than Ø0,2 mm (A wire could be used as test object) between the ECA and gearbox flange, so that the object enters the space behind the ECA.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Low Proposal Ready Open point: - | DetailsFull requirement text 4.6 When the ECA is assembled, it shall not be possible to insert an object larger than Ø0,2 mm (A wire could be used as test object) between the ECA and gearbox flange, so that the object enters the space behind the ECA. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Medium, IT High, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00082 | 4.7 When the ECA is assembled, a gap of 3,5 mm towards surface B with a profile tolerance of ±1 mm to the nominal dimensions shall be provided.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 4.7 When the ECA is assembled, a gap of 3,5 mm towards surface B with a profile tolerance of ±1 mm to the nominal dimensions shall be provided. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00083 | The surface roughness of the ECA opposite to surface B shall be equal or finer than Ra 3,2 µm.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text The surface roughness of the ECA opposite to surface B shall be equal or finer than Ra 3,2 µm. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00084 | 4.8 The ECA shall be adapted for 6 pcs M8 flange screws described by Scania STD4435Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 4.8 The ECA shall be adapted for 6 pcs M8 flange screws described by Scania STD4435 Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00085 | P 1 Page 4.9 The ECA shall be adapted for 2 pcs 10 mm guide pins.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text P 1 Page 4.9 The ECA shall be adapted for 2 pcs 10 mm guide pins. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00086 | Figure 5Gearbox flange 4.10 The guide pin holes in the ECA shall be Ø 10,1±0.05 mm and at least 12 mm deep.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text Figure 5 - Gearbox flange 4.10 The guide pin holes in the ECA shall be Ø 10,1±0.05 mm and at least 12 mm deep. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00087 | The holes shall also block the guide pin from protruding more than 14 mm from the gearbox housing.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text The holes shall also block the guide pin from protruding more than 14 mm from the gearbox housing. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00088 | 4.11 The ECA shall be able to be held by the guide pins only while being exposed to the max clutch load, (req.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-001 | Low Proposal Ready Open point: - | DetailsFull requirement text 4.11 The ECA shall be able to be held by the guide pins only while being exposed to the max clutch load, (req. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00089 | Surface indents in the contacts are allowed as long as the structural integrity is unaffected 4.12 The pushrod end that makes contact with the clutch lever shall be a Ø15,93±0,07 mm steel sphere.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DAI-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text Surface indents in the contacts are allowed as long as the structural integrity is unaffected 4.12 The pushrod end that makes contact with the clutch lever shall be a Ø15,93±0,07 mm steel sphere. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DAI-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00090 | 4.13 It shall be possible to pull the pushrod 50 times with a force of 300 N without risk for it to come loose from the ECA.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 4.13 It shall be possible to pull the pushrod 50 times with a force of 300 N without risk for it to come loose from the ECA. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00091 | Alternatively it can have a loose fit in the ECA, but it shall be possible to reconnect it by pushing it back by hand.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text Alternatively it can have a loose fit in the ECA, but it shall be possible to reconnect it by pushing it back by hand. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00092 | 4.14 The ECA shall allow space for external tools according to the cylinders in the 3D envelope attached.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 4.14 The ECA shall allow space for external tools according to the cylinders in the 3D envelope attached. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00093 | 4.15 The ECA shall have a window where the volume shown in Figure 6 – Snap in tool space, could pass through(See req.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Engineering tooling Architecture: Engineering Toolchain SSR: SSR-TOOL-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text 4.15 The ECA shall have a window where the volume shown in Figure 6 – Snap in tool space, could pass through(See req. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Engineering tooling | Security capability: None | Interface: None | Architecture: Engineering Toolchain | Work product: Requirement traceability record | SSR: SSR-TOOL-004 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00094 | 4.16 The ECA shall provide a support for a clutch snap in tool on the marked surface in Figure 4ISO view of 3D envelope.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Engineering tooling Architecture: Engineering Toolchain SSR: SSR-TOOL-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text 4.16 The ECA shall provide a support for a clutch snap in tool on the marked surface in Figure 4 - ISO view of 3D envelope. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Engineering tooling | Security capability: None | Interface: None | Architecture: Engineering Toolchain | Work product: Requirement traceability record | SSR: SSR-TOOL-004 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00095 | P 1 Page 4.17 The hole shall be equipped with a cover possible to assemble and disassemble at least 50 times without tools.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text P 1 Page 4.17 The hole shall be equipped with a cover possible to assemble and disassemble at least 50 times without tools. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00096 | If an interference fit is chosen, the maximum force to assemble/disassemble shall be 50 N in room temperature.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text If an interference fit is chosen, the maximum force to assemble/disassemble shall be 50 N in room temperature. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| req.10.5 | It shall still remain intac t and keep tightness after vibration testing (See req.10.5) 4.18 When the cover is assembled it shall not be possible to insert an object larger than Ø0,2 mm into the gearbox housing between the cover and ECA.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Low Proposal Ready Open point: - | DetailsFull requirement text It shall still remain intac t and keep tightness after vibration testing (See req.10.5) 4.18 When the cover is assembled it shall not be possible to insert an object larger than Ø0,2 mm into the gearbox housing between the cover and ECA. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Medium, IT High, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00098 | Figure 6Snap in tool space 4.19 The ECA shall have a loop or similar feature where the cable can be fixated with a cable tie.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Engineering tooling Architecture: Engineering Toolchain SSR: SSR-COM-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text Figure 6 - Snap in tool space 4.19 The ECA shall have a loop or similar feature where the cable can be fixated with a cable tie. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Engineering tooling | Security capability: None | Interface: None | Architecture: Engineering Toolchain | Work product: Requirement traceability record | SSR: SSR-COM-004 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00099 | The loop or Scania assembled bracket shall be located close to the centre ( ± 20 mm) of the cable section between the connector and last cable fixation point on the gearbox 4.20 The connector for communication and power shall be positioned as indicated in Figure 4 - ISO view of 3D envelope, when connected.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Hardware platform support Architecture: Hardware Platform SSR: SSR-COM-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text The loop or Scania assembled bracket shall be located close to the centre ( ± 20 mm) of the cable section between the connector and last cable fixation point on the gearbox 4.20 The connector for communication and power shall be positioned as indicated in Figure 4 - ISO view of 3D envelope, when connected. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-COM-005 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00100 | Details regarding actual length and positioning tolerances shall be agreed in design phase.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text Details regarding actual length and positioning tolerances shall be agreed in design phase. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00101 | 4.21 If the ECA is powered up with the PP in the utmost forward position (for example when not connected to the clutch lever) it shall move AP to its utmost reversed position.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 4.21 If the ECA is powered up with the PP in the utmost forward position (for example when not connected to the clutch lever) it shall move AP to its utmost reversed position. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00102 | 4.23 The actuator shall apply a preload force for the release bearing.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text 4.23 The actuator shall apply a preload force for the release bearing. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00103 | The preload force measured on the push rod shall be 150N to 250N independent of the clutch position 4.24 The pushrod position when clutch is at rest and only preload force is applied, will vary randomly within 2 mm (± 1mm from FCCP).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Low Proposal Ready Open point: - | DetailsFull requirement text The preload force measured on the push rod shall be 150N to 250N independent of the clutch position 4.24 The pushrod position when clutch is at rest and only preload force is applied, will vary randomly within 2 mm (± 1mm from FCCP). Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00104 | 4.25 It must be possible to assemble the actuator independent of the lever position without any power connection.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 4.25 It must be possible to assemble the actuator independent of the lever position without any power connection. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00105 | This means that the push rod shall be possible to move by hand.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text This means that the push rod shall be possible to move by hand. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00106 | 4.26 When the clutch is fully engaged, the active control mode is position or torque control mode and there is no active request to extract the pushrod (clutch opening motion), the ECA shall not apply a force outside of limits in preload force defined in req.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Low Proposal Ready Open point: - | DetailsFull requirement text 4.26 When the clutch is fully engaged, the active control mode is position or torque control mode and there is no active request to extract the pushrod (clutch opening motion), the ECA shall not apply a force outside of limits in preload force defined in req. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| req-5.10 | P 1 Page 5 Clutch engage and disengage 5.1 It shall be possible to disengage the clutch in 180ms (= Ts) with accuracy according to req 5.10,and max speed set to 125mm/s (see req 6.4) Time is measured according to Figure 7 – Max disengage time, where the dashed line is the position request as it becomes available on the CAN bus, and the full line is the actual PP.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text P 1 Page 5 Clutch engage and disengage 5.1 It shall be possible to disengage the clutch in 180ms (= Ts) with accuracy according to req 5.10,and max speed set to 125mm/s (see req 6.4) Time is measured according to Figure 7 – Max disengage time, where the dashed line is the position request as it becomes available on the CAN bus, and the full line is the actual PP. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 13 · page 13 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00108 | This shall be measured against the maximum disengage force (See Appendix A) Figure 7 – Maximum disengage timeExpectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text This shall be measured against the maximum disengage force (See Appendix A) Figure 7 – Maximum disengage time Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 13 · page 13 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| req-6.4 | P 1 Page 5.2 It shall be possible to engage the clutch in 180ms (=Ts) with accuracy according to re q.5.10, and the max speed set to 125mm/s (see req 6.4).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text P 1 Page 5.2 It shall be possible to engage the clutch in 180ms (=Ts) with accuracy according to re q.5.10, and the max speed set to 125mm/s (see req 6.4). Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 14 · page 14 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00110 | This shall be measured against the minimum engage force (See Appendix A) Figure 8Maximum engage timeExpectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text This shall be measured against the minimum engage force (See Appendix A) Figure 8 - Maximum engage time Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 14 · page 14 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00111 | P 1 Page 5.3 The clutch actuator shall report the absolute position of the current actuator stroke (AP) (Ref 14.14).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text P 1 Page 5.3 The clutch actuator shall report the absolute position of the current actuator stroke (AP) (Ref 14.14). Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 15 · page 15 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00112 | 5.4 It shall also report the position that corresponds to a fully closed clutch position (FCCP), expressed in absolute position of the actuator stroke and relative to the absolute zero position (See req.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.4 It shall also report the position that corresponds to a fully closed clutch position (FCCP), expressed in absolute position of the actuator stroke and relative to the absolute zero position (See req. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 15 · page 15 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00113 | 5.5 The clutch actuator shall be equipped with a displacement sensor measuring the movement of the push rod, (Ref 14.14) 5.6 The actuator must be able to determine the pushrod position according to the following: Accuracy (maximum difference between measured pushrod position and actual pushrod position): +/- 1.6mm.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Hardware platform support Architecture: Hardware Platform SSR: SSR-HW-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.5 The clutch actuator shall be equipped with a displacement sensor measuring the movement of the push rod, (Ref 14.14) 5.6 The actuator must be able to determine the pushrod position according to the following: Accuracy (maximum difference between measured pushrod position and actual pushrod position): +/- 1.6mm. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-HW-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 15 · page 15 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00114 | Range: 85mm (AP) 5.7 For each stroke that the actuator performs it shall adjust to the current wear of the clutch.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text Range: 85mm (AP) 5.7 For each stroke that the actuator performs it shall adjust to the current wear of the clutch. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 15 · page 15 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00115 | This means that is shall be possible to request a relative stroke from the fully closed clutch position and achieve the step accuracy as defined in req.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text This means that is shall be possible to request a relative stroke from the fully closed clutch position and achieve the step accuracy as defined in req. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 15 · page 15 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00116 | The FCCP after a clutch engage shall be updated to 90% of the step within 0,2 s per mm that the FCCP have changed during the stroke.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | High Proposal Ready Open point: - | DetailsFull requirement text The FCCP after a clutch engage shall be updated to 90% of the step within 0,2 s per mm that the FCCP have changed during the stroke. Engineering expectation Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 15 · page 15 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00117 | 5.9 The maximum stationary position error relative to real FCCP (i e self-adjustment error + step response error) shall be ±0.15mm.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.9 The maximum stationary position error relative to real FCCP (i e self-adjustment error + step response error) shall be ±0.15mm. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 15 · page 15 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00118 | P 1 Page 5.10 The actuator shall move the pushrod according to the following points: Actuator maximum speed: The maximum achievable speed of the pushrod shall be at least 125 mm/s.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text P 1 Page 5.10 The actuator shall move the pushrod according to the following points: Actuator maximum speed: The maximum achievable speed of the pushrod shall be at least 125 mm/s. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 16 · page 16 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00119 | The actuator shall move the pushrod at the highest possible speed, limited only by its maximum achievable speed and the maximum speed request.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Low Proposal Ready Open point: - | DetailsFull requirement text The actuator shall move the pushrod at the highest possible speed, limited only by its maximum achievable speed and the maximum speed request. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 16 · page 16 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00120 | 6.4) Dynamics start of movement: The requested speed (or 125mm/s, if requested speed > 125mm/s) shall be achieved within 50ms from when a new value for requested position is sent.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text 6.4) Dynamics start of movement: The requested speed (or 125mm/s, if requested speed > 125mm/s) shall be achieved within 50ms from when a new value for requested position is sent. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 16 · page 16 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00121 | Dynamics end of movement: The requested speed shall be kept until 2 mm from the target position.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text Dynamics end of movement: The requested speed shall be kept until 2 mm from the target position. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 16 · page 16 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00122 | 100ms after reaching 2 mm from target, the maximum position error should be ±0.1mm.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Needs Internal Review | Needs internal review. Confirm whether this should-level requirement is in the committed baseline.Decision: Complete internal review of wording and baseline scope. | None | Feature / interface: System behavior Architecture: System Core SSR: None | Low Reviewed Internally Open point: - | DetailsFull requirement text 100ms after reaching 2 mm from target, the maximum position error should be ±0.1mm. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Needs internal review. Confirm whether this should-level requirement is in the committed baseline. Rationale Non-mandatory wording; baseline inclusion not yet confirmed. Implementation approach Decide baseline inclusion internally, then issue an Accept/Partial position. Acceptance condition Internal baseline decision recorded. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 16 · page 16 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Complete internal review of wording and baseline scope. |
| req-5.1 | The full strokes should be performed within 180 ms, as specified in req 5.1 and 5.2.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: Compliance Process; System Core SSR: SSR-SYS-009 | Medium Proposal Ready Open point: - | DetailsFull requirement text The full strokes should be performed within 180 ms, as specified in req 5.1 and 5.2. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process; System Core | Work product: DIA / cybersecurity case | SSR: SSR-SYS-009 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 16 · page 16 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00124 | 5.10 shall be tested with a step response test cycle, according to description and Figure 10Step response test cycle.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.10 shall be tested with a step response test cycle, according to description and Figure 10 - Step response test cycle. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 17 · page 17 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00125 | P 1 Page 5.12 The ECA shall be able to run the 4 second test cycle in Figure 11Release frequency test continuously for 5 hours without any degradation or failure.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text P 1 Page 5.12 The ECA shall be able to run the 4 second test cycle in Figure 11 - Release frequency test continuously for 5 hours without any degradation or failure. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 18 · page 18 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| req-8.1 | The test shall be done with the highest operating temperature (see req 8.1) and maximum clutch force (See Appendix A) Figure 11 - Release frequency testExpectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text The test shall be done with the highest operating temperature (see req 8.1) and maximum clutch force (See Appendix A) Figure 11 - Release frequency test Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 18 · page 18 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00127 | Between 16V and loss of power the ECA shall hold its current position or move towards requested position without any time requirement.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text Between 16V and loss of power the ECA shall hold its current position or move towards requested position without any time requirement. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 19 · page 19 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00128 | The strategy shall be disc ussed and approved with Traton.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text The strategy shall be disc ussed and approved with Traton. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 19 · page 19 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00129 | 5.1 and 5.2) Figure 12Class B exceptions 5.14 It shall be possible to keep the clutch disengaged continuously without risk of loss of function for 120 min.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.1 and 5.2) Figure 12 - Class B exceptions 5.14 It shall be possible to keep the clutch disengaged continuously without risk of loss of function for 120 min. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 19 · page 19 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00130 | This shall be measured against the maximum disengage force (Appendix A) and an highest operating temperature (see req.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text This shall be measured against the maximum disengage force (Appendix A) and an highest operating temperature (see req. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 19 · page 19 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00131 | P 1 Page 6 SW functionality 6.1 TB4684 shall be applied.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text P 1 Page 6 SW functionality 6.1 TB4684 shall be applied. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 20 · page 20 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00132 | It shall be followed to its full extent.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text It shall be followed to its full extent. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 20 · page 20 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00133 | When requesting Absolute Position Control the actuator shall move to the actuator position defined by the Requested Position (RP).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text When requesting Absolute Position Control the actuator shall move to the actuator position defined by the Requested Position (RP). Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 21 · page 21 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00134 | Specific cases shall be approved with Traton.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text Specific cases shall be approved with Traton. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 21 · page 21 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00135 | Control mode Absolute position 0x01 6.3.2 When requesting Relative Position Control (RPC) the actuator shall move to an offset that corresponds to the Requested Position from the Fully Closed Clutch Position (FCCP).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text Control mode Absolute position 0x01 6.3.2 When requesting Relative Position Control (RPC) the actuator shall move to an offset that corresponds to the Requested Position from the Fully Closed Clutch Position (FCCP). Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 21 · page 21 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00136 | Control mode Relative position 0x02 6.3.3 When requesting Torque Control (TC) the actuator shall actuate the requested motor torque.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text Control mode Relative position 0x02 6.3.3 When requesting Torque Control (TC) the actuator shall actuate the requested motor torque. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 21 · page 21 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00137 | 6.3.4 When requesting Test Mode, the actuator shall perform tests to detect latent faults.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text 6.3.4 When requesting Test Mode, the actuator shall perform tests to detect latent faults. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 22 · page 22 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00138 | ECA behavior and additional requirements for this mode can be found in (Ref 14.16) Control mode Test mode 0x04 6.3.5 When this Control Mode is sent the actuator shall behave as if the power supply was cut with aspect to control of the actuator.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text ECA behavior and additional requirements for this mode can be found in (Ref 14.16) Control mode Test mode 0x04 6.3.5 When this Control Mode is sent the actuator shall behave as if the power supply was cut with aspect to control of the actuator. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 22 · page 22 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00139 | CAN communication shall still be active.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text CAN communication shall still be active. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 22 · page 22 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00140 | If the actuator can move faster than this value it shall be controlled in a such way that it does not exceed this limit.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text If the actuator can move faster than this value it shall be controlled in a such way that it does not exceed this limit. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 22 · page 22 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00141 | 6.5 Self-adjustment The self-adjustment signal defines the restrictions of how the FCCP shall be identified.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text 6.5 Self-adjustment The self-adjustment signal defines the restrictions of how the FCCP shall be identified. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 22 · page 22 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| req-6.3 | The signal is valid during Control Modes RPC and TC(see req 6.3).Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text The signal is valid during Control Modes RPC and TC(see req 6.3). Engineering expectation Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 22 · page 22 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00143 | The value of the FCCP shall be reported via CAN(Ref 14.14) Req.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text The value of the FCCP shall be reported via CAN(Ref 14.14) Req. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 22 · page 22 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00144 | The value shall be frozen at the last identified position and used for RPC.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text The value shall be frozen at the last identified position and used for RPC. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 22 · page 22 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00145 | 6.6.1 When low accuracy mode is requested, the maximum push rod position(PP) error can be ±0.5mm Accuracy mode Low accuracy 0x0 6.6.2 Accuracy according to 5.10 shall be fulfilled.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text 6.6.1 When low accuracy mode is requested, the maximum push rod position(PP) error can be ±0.5mm Accuracy mode Low accuracy 0x0 6.6.2 Accuracy according to 5.10 shall be fulfilled. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 23 · page 23 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00146 | Message contents to be agreed with Traton 6.9 ECA identification number: The ECA shall report a unique ECA individual identification number 6.10 Supplier code: The ECA shall report supplier code 5 via CAN.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Needs Customer Clarification | Needs customer clarification. The requirement implies customer-owned infrastructure, approval, or a responsibility split that is not yet available.Decision: Send linked open point to the customer for decision. | None | Feature / interface: External interfaces / External Interfaces; OEM/Customer Review Interface Architecture: External Interfaces; OEM/Customer Review Interface SSR: None | Unknown Reviewed Internally Open point: OP-011 | DetailsFull requirement text Message contents to be agreed with Traton 6.9 ECA identification number: The ECA shall report a unique ECA individual identification number 6.10 Supplier code: The ECA shall report supplier code 5 via CAN. Engineering expectation Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Supplier proposal Needs customer clarification. The requirement implies customer-owned infrastructure, approval, or a responsibility split that is not yet available. Rationale Flagged customer_clarification_needed=yes during extraction. Implementation approach Hold implementation; raise an open point and a clarification question. Acceptance condition Customer answers the linked open point. Customer feedback - Customer decision - Customer clarification / open point Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline. Traceability Feature: External interfaces | Security capability: None | Interface: External Interfaces; OEM/Customer Review Interface | Architecture: External Interfaces; OEM/Customer Review Interface | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 23 · page 23 Estimation / resource / tool / IT / hardware impact Effort Unknown, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Scope and effort cannot be frozen; estimation carries an open assumption and downstream design may rework. Next action Send linked open point to the customer for decision. |
| REQ-AUTO-00147 | 6.11 SW number: The ECA shall report a complete SW version number.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text 6.11 SW number: The ECA shall report a complete SW version number. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 23 · page 23 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00148 | 6.12 HW number: The ECA shall report a complete HW version number.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text 6.12 HW number: The ECA shall report a complete HW version number. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 23 · page 23 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| req-6.20 | 6.13 Error State DiagnosticESD and Error State Action - ESA The ECA shall send a bit field via CAN containing errors present Additionally, see req 6.20, req 6.22 ,req.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Validate assumption with customer; complete mapping; implement. | Diagnostic security | Feature / interface: Diagnostic security Architecture: Security Services SSR: SSR-RBAC-001 | High Proposal Ready Open point: - | DetailsFull requirement text 6.13 Error State Diagnostic - ESD and Error State Action - ESA The ECA shall send a bit field via CAN containing errors present Additionally, see req 6.20, req 6.22 ,req. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Diagnostic security | Security capability: Diagnostic security | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 23 · page 23 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00150 | ESA definition( Ref 14.16) The supplier shall provide documentation for the ESD bits and related faults .Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Security evidence and traceability / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text ESA definition( Ref 14.16) The supplier shall provide documentation for the ESD bits and related faults . Engineering expectation Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 23 · page 23 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00151 | 6.14 System state The ECA shall report its current System State.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text 6.14 System state The ECA shall report its current System State. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 23 · page 23 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00152 | 6.14.1 Boot Mode If the actuator is in boot mode, 0x00 shall be reported as active state.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text 6.14.1 Boot Mode If the actuator is in boot mode, 0x00 shall be reported as active state. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 24 · page 24 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00153 | 0x0 6.14.2 Absolute Position Control This value shall be sent when the ECA is actuating Absolute Position Control.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text 0x0 6.14.2 Absolute Position Control This value shall be sent when the ECA is actuating Absolute Position Control. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 24 · page 24 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00154 | 0x1 6.14.3 Relative Position Control This value shall be sent when the ECA is actuating Relative Position Control.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text 0x1 6.14.3 Relative Position Control This value shall be sent when the ECA is actuating Relative Position Control. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 24 · page 24 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00155 | 0x2 6.14.4 Torque Control This value shall be sent when the ECA is actuating Torque Control.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text 0x2 6.14.4 Torque Control This value shall be sent when the ECA is actuating Torque Control. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 24 · page 24 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00156 | 0x4 6.14.5 Self-Adjustment This value shall be sent when the ECA is performing a Self-Adjustment procedure that is not part of a RPC or TC request (i.e.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text 0x4 6.14.5 Self-Adjustment This value shall be sent when the ECA is performing a Self-Adjustment procedure that is not part of a RPC or TC request (i.e. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 24 · page 24 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00157 | 0x5 6.14.6 Initializing This value shall be sent when the ECA is performing its initiation routine and is not yet available for control.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text 0x5 6.14.6 Initializing This value shall be sent when the ECA is performing its initiation routine and is not yet available for control. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 24 · page 24 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00158 | 0xA 6.14.7 Shut down This value shall be sent when the ECA is performing its shut down routing and is not available for control.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text 0xA 6.14.7 Shut down This value shall be sent when the ECA is performing its shut down routing and is not available for control. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 24 · page 24 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00159 | 0xB 6.14.8 Debug / Test This value shall be sent when the actuator is in debug or test control state.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text 0xB 6.14.8 Debug / Test This value shall be sent when the actuator is in debug or test control state. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 24 · page 24 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00160 | 0xC 6.14.9 Motor Brake Simulation This value shall be sent when the actuator is performing a motor brake simulation.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text 0xC 6.14.9 Motor Brake Simulation This value shall be sent when the actuator is performing a motor brake simulation. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 24 · page 24 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00161 | P 1 Page 6.15 System Temperature The ECA shall report the current system temperature.(Ref 14.14) 6.16 Torque Feedback The ECA shall calculate and report the actuator motor torque.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text P 1 Page 6.15 System Temperature The ECA shall report the current system temperature.(Ref 14.14) 6.16 Torque Feedback The ECA shall calculate and report the actuator motor torque. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 25 · page 25 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00162 | (Ref 14.14) 6.17 Current feedback The ECA shall report the current for each phase of the actuator.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text (Ref 14.14) 6.17 Current feedback The ECA shall report the current for each phase of the actuator. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 25 · page 25 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00163 | These values shall be calculated using a moving mean filter.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text These values shall be calculated using a moving mean filter. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 25 · page 25 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00164 | The filter time shall equal the update frequency .Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | High Proposal Ready Open point: - | DetailsFull requirement text The filter time shall equal the update frequency . Engineering expectation Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 25 · page 25 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00165 | (Ref 14.14) 6.18 Supply Voltage Feedback The ECA shall report the current system voltage.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text (Ref 14.14) 6.18 Supply Voltage Feedback The ECA shall report the current system voltage. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 25 · page 25 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| Req.ID-Description-6.19.1 | (input voltage) (Ref 14.14) 6.19 Operational data The following operational data deemed important to store (req.6.16.1, req 6.16.2) (Ref 14.14) Req.ID Description 6.19.1 Operational hours: The ECA shall store and report its accumulated operational hours.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text (input voltage) (Ref 14.14) 6.19 Operational data The following operational data deemed important to store (req.6.16.1, req 6.16.2) (Ref 14.14) Req.ID Description 6.19.1 Operational hours: The ECA shall store and report its accumulated operational hours. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 25 · page 25 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00167 | 6.19.2 Total travelled length: The ECA shall report its accumulated lifetime travel length.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text 6.19.2 Total travelled length: The ECA shall report its accumulated lifetime travel length. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 25 · page 25 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00168 | 6.20 Diagnosis: CVS120 shall be applied (Ref 14.12).Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text 6.20 Diagnosis: CVS120 shall be applied (Ref 14.12). Engineering expectation Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 25 · page 25 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00169 | 6.21 Cyber Security: Cybersecurity shall be considered through a separate process with the latest Traton workflow in mind.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | Cybersecurity requirement handling | Feature / interface: Cybersecurity requirement handling Architecture: Security Services SSR: SSR-CON-001 | High Proposal Ready Open point: - | DetailsFull requirement text 6.21 Cyber Security: Cybersecurity shall be considered through a separate process with the latest Traton workflow in mind. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Cybersecurity requirement handling | Security capability: Cybersecurity requirement handling | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-CON-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 25 · page 25 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| Req.ID-Description-6.22.1 | Req.ID Description 6.22.1 Wrong rotation direction 6.22.2 Short circuit / open load on the phases 6.22.3 Motor rotation feedback, short circuit / open loadExpectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text Req.ID Description 6.22.1 Wrong rotation direction 6.22.2 Short circuit / open load on the phases 6.22.3 Motor rotation feedback, short circuit / open load Engineering expectation Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 25 · page 25 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00171 | P 1 Page 6.22.4 Positions sensor short circuit / open load (if used) 6.22.5 Watchdog error 6.22.6 Low voltage 30 6.22.7 CAN-timeout (stored and sent when possible) 6.22.8 High temperature/current consumption (system needs to indicate abnormal usage that can damage the device), indicate a self-protective mode (if applicable) 6.22.9 Error on temperature sensor 6.22.10 High friction in mechanical system 6.22.11 Other electrical HW errorExpectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text P 1 Page 6.22.4 Positions sensor short circuit / open load (if used) 6.22.5 Watchdog error 6.22.6 Low voltage 30 6.22.7 CAN-timeout (stored and sent when possible) 6.22.8 High temperature/current consumption (system needs to indicate abnormal usage that can damage the device), indicate a self-protective mode (if applicable) 6.22.9 Error on temperature sensor 6.22.10 High friction in mechanical system 6.22.11 Other electrical HW error Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 26 · page 26 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test High Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00172 | P 1 Page 6.23 Validation and Invalidation: The reported ESD must be able to be validated and invalidated.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Security evidence and traceability / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-VV-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text P 1 Page 6.23 Validation and Invalidation: The reported ESD must be able to be validated and invalidated. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-VV-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 27 · page 27 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00173 | 6.24 Diagnosis tracking: The gearbox control unit(TCU) shall be responsible for setting DTCs based on received notifications from ECA via ESD, including time-stamps, occurrence counters etc.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 6.24 Diagnosis tracking: The gearbox control unit(TCU) shall be responsible for setting DTCs based on received notifications from ECA via ESD, including time-stamps, occurrence counters etc. Engineering expectation Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 27 · page 27 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00174 | If higher resolution is required for the supplier to properly troubleshoot any individual occurrence, then the ECA is responsible for storing these parameters internally.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text If higher resolution is required for the supplier to properly troubleshoot any individual occurrence, then the ECA is responsible for storing these parameters internally. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 27 · page 27 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00175 | Internally stored parameters may be accessible only using supplier defined tools .Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: None | Low Proposal Ready Open point: - | DetailsFull requirement text Internally stored parameters may be accessible only using supplier defined tools . Engineering expectation Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Constraint (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 27 · page 27 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00176 | 6.25 Data logging: Any data logged or stored shall be agreed upon together with Traton.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text 6.25 Data logging: Any data logged or stored shall be agreed upon together with Traton. Engineering expectation Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 27 · page 27 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00177 | 6.26 Data storage: When storing data in the device, the supplier shall take measures to prevent corruption of data which can occur for example when suffering power loss during read or write cycles.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces / External Interfaces; OEM/Customer Review Interface Architecture: External Interfaces; OEM/Customer Review Interface SSR: SSR-COM-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text 6.26 Data storage: When storing data in the device, the supplier shall take measures to prevent corruption of data which can occur for example when suffering power loss during read or write cycles. Engineering expectation Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces | Security capability: None | Interface: External Interfaces; OEM/Customer Review Interface | Architecture: External Interfaces; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 27 · page 27 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00178 | The supplier shall also ensure that systems are in place that ensure that data corruption is handled without loss of data, or loss of function.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior / OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text The supplier shall also ensure that systems are in place that ensure that data corruption is handled without loss of data, or loss of function. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Application Software; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 27 · page 27 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00179 | 6.27 Calibration: There shall only be one calibration set of the ECA that is delivered to Traton, i.e, the calibration shall not be dependent of installation variants.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Low Proposal Ready Open point: - | DetailsFull requirement text 6.27 Calibration: There shall only be one calibration set of the ECA that is delivered to Traton, i.e, the calibration shall not be dependent of installation variants. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 27 · page 27 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Medium, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00180 | 6.28 Reset: It shall be possible to reset the ECA application with a power off/on cycle after all functional safety events.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text 6.28 Reset: It shall be possible to reset the ECA application with a power off/on cycle after all functional safety events. Engineering expectation Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 27 · page 27 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00181 | ID General electrical requirements 7.1 The electrical design must ensure that an internal short circuit through one of H -bridges (“shoot- through”) is avoided.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text ID General electrical requirements 7.1 The electrical design must ensure that an internal short circuit through one of H -bridges (“shoot- through”) is avoided. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 28 · page 28 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00182 | 7.2 Short circuit protection shall be implemented by hardware.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Hardware platform support Architecture: Hardware Platform SSR: SSR-HW-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 7.2 Short circuit protection shall be implemented by hardware. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-HW-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 28 · page 28 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00183 | 7.3 A safe boot sequence must be set to prevent unwanted or undefined behavior during or after loss of power, or corruption of stored data.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text 7.3 A safe boot sequence must be set to prevent unwanted or undefined behavior during or after loss of power, or corruption of stored data. Engineering expectation Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 28 · page 28 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00184 | 7.4 A safe memory read/write sequence must also be implemented during actuator movement, in order to ensure safe and predictable behavior during operation, or in case of power lo ss.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Hardware platform support Architecture: Hardware Platform SSR: SSR-HW-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 7.4 A safe memory read/write sequence must also be implemented during actuator movement, in order to ensure safe and predictable behavior during operation, or in case of power lo ss. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-HW-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 28 · page 28 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| Req.ID-Connector-Requirements-7.5 | Req.ID Connector Requirements 7.5 All external electrical connectors shall be geometrically coded.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Hardware platform support Architecture: Hardware Platform SSR: SSR-HW-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text Req.ID Connector Requirements 7.5 All external electrical connectors shall be geometrically coded. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-HW-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 28 · page 28 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00186 | If internal components are included in repair kits, the internal electrical connectors shall also be geometrically coded.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | High Proposal Ready Open point: - | DetailsFull requirement text If internal components are included in repair kits, the internal electrical connectors shall also be geometrically coded. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 28 · page 28 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00187 | 7.8 ECU tab headers shall comply with TB1787.(Ref 14.6) 7.9 ECU tab headers shall be made of self-extinguishing materials (i.e.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Hardware platform support Architecture: Hardware Platform SSR: SSR-HW-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 7.8 ECU tab headers shall comply with TB1787.(Ref 14.6) 7.9 ECU tab headers shall be made of self-extinguishing materials (i.e. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-HW-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 28 · page 28 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00188 | All power used by the ECA shall be taken from this battery connection.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text All power used by the ECA shall be taken from this battery connection. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 29 · page 29 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00189 | The ground shall not be DC connected to the ECA housing.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Low Proposal Ready Open point: - | DetailsFull requirement text The ground shall not be DC connected to the ECA housing. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 29 · page 29 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00190 | 7.17 Umax:- 32/36/48 A Specific test relations TBD 7.18 Umin: 16 - - V CVS41 limits may go below this value.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | Low Proposal Ready Open point: - | DetailsFull requirement text 7.17 Umax: - - 32/36/48 A Specific test relations TBD 7.18 Umin: 16 - - V CVS41 limits may go below this value. Engineering expectation Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 29 · page 29 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00191 | 7.23 Quiescent current: According to CVS41 (Ref 14.2), must be met independent of input and output conditions.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text 7.23 Quiescent current: According to CVS41 (Ref 14.2), must be met independent of input and output conditions. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 30 · page 30 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00192 | It shall be used to control the power up sequence to the µP.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text It shall be used to control the power up sequence to the µP. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 31 · page 31 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00193 | The Wake-up signal shall also be connected to a digital input on the µP.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text The Wake-up signal shall also be connected to a digital input on the µP. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 31 · page 31 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00194 | Special precautions shall be taken to prevent direct connection between Wake-up and 30 in case of a single failure.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text Special precautions shall be taken to prevent direct connection between Wake-up and 30 in case of a single failure. Engineering expectation Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 31 · page 31 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00195 | After the wake-up line goes to high state: The ECA shall communicate on the CAN line within 250ms in case of a normal start -up The ECA shall be ready to open the clutch within 350ms in case of a normal start -up The ECA shall be ready to open the clutch as soon as possible after necessary movements in case of an abnormal start-up.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text After the wake-up line goes to high state: The ECA shall communicate on the CAN line within 250ms in case of a normal start -up The ECA shall be ready to open the clutch within 350ms in case of a normal start -up The ECA shall be ready to open the clutch as soon as possible after necessary movements in case of an abnormal start-up. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 31 · page 31 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00196 | After movement and reset, the ECA shall communicate on the CAN line within 250ms After movement and reset, the ECA shall be ready to open the clutch within 400ms In the case if the wake-up goes "high" at the same time as U30 signal the ECA should be ready to open the clutch within 3 seconds.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text After movement and reset, the ECA shall communicate on the CAN line within 250ms After movement and reset, the ECA shall be ready to open the clutch within 400ms In the case if the wake-up goes "high" at the same time as U30 signal the ECA should be ready to open the clutch within 3 seconds. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 31 · page 31 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00197 | Definition ready to open clutch: The actuator position shall be between FCCP and FCCP -3mm and the ECA is capable to move to disengaged clutch directly when requeste d.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text Definition ready to open clutch: The actuator position shall be between FCCP and FCCP -3mm and the ECA is capable to move to disengaged clutch directly when requeste d. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 31 · page 31 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00198 | Redundancies due improper shutdown shall be aligned with Traton.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text Redundancies due improper shutdown shall be aligned with Traton. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 31 · page 31 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00199 | If a signal for disengaging the clutch is received the ECA shall actuate the request regardless of CAN-request.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text If a signal for disengaging the clutch is received the ECA shall actuate the request regardless of CAN-request. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 33 · page 33 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00200 | Any watchdog circuit shall have no influence on the CAN bus.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text Any watchdog circuit shall have no influence on the CAN bus. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 34 · page 34 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00201 | The CAN front end shall be designed to comply with TB1905 (Ref 14.3), with the following additional information in this chapter.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text The CAN front end shall be designed to comply with TB1905 (Ref 14.3), with the following additional information in this chapter. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 34 · page 34 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00202 | 7.35 The controller and transceiver shall be CAN FD ready.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text 7.35 The controller and transceiver shall be CAN FD ready. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 34 · page 34 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00203 | 7.36 Termination resistance:2 x 60 - Ω 1% resistors shall be used 7.37 Baud rate: 250 500 1000 kbit/s Flashing in production shall be possible with 1000kbit/s.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Secure software update and flash readiness Architecture: System Core SSR: SSR-UPD-001 | High Proposal Ready Open point: - | DetailsFull requirement text 7.36 Termination resistance: - 2 x 60 - Ω 1% resistors shall be used 7.37 Baud rate: 250 500 1000 kbit/s Flashing in production shall be possible with 1000kbit/s. Engineering expectation Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-UPD-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 34 · page 34 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Medium, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00204 | ID Requirements 7.39 Note: The layout shall always be present on the PCB and the supplier must be flexible in changing/removing the CAN related components in this section.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces / External Interfaces; OEM/Customer Review Interface Architecture: External Interfaces; OEM/Customer Review Interface SSR: SSR-COM-002 | High Proposal Ready Open point: - | DetailsFull requirement text ID Requirements 7.39 Note: The layout shall always be present on the PCB and the supplier must be flexible in changing/removing the CAN related components in this section. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces | Security capability: None | Interface: External Interfaces; OEM/Customer Review Interface | Architecture: External Interfaces; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 35 · page 35 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00205 | The components shall not be populated by default.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Low Proposal Ready Open point: - | DetailsFull requirement text The components shall not be populated by default. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 35 · page 35 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00206 | The CAN front end shall be designed to comply with TB1905.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text The CAN front end shall be designed to comply with TB1905. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 35 · page 35 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00207 | The quality of the wire bonding and position shall be properly analyzed.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text The quality of the wire bonding and position shall be properly analyzed. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 36 · page 36 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00208 | The material shall be lead free and of ”high temperatures solder type”.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text The material shall be lead free and of ”high temperatures solder type”. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 36 · page 36 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00209 | The melting point of the soldering material and the composition of the soldering material shall be declared by supplier.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text The melting point of the soldering material and the composition of the soldering material shall be declared by supplier. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 36 · page 36 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00210 | The PCB must be supported and must not bent in any direction during the process.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-SYS-009 | Low Proposal Ready Open point: - | DetailsFull requirement text The PCB must be supported and must not bent in any direction during the process. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-SYS-009 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 36 · page 36 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00211 | Conformal coating or lacquer shall cover the entire PCB and all solder joints.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text Conformal coating or lacquer shall cover the entire PCB and all solder joints. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 36 · page 36 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00212 | The layout of the PCB, including component placement, shall take the applying of conformal coating into consideration so that the aforementioned requirement can be met.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | High Proposal Ready Open point: - | DetailsFull requirement text The layout of the PCB, including component placement, shall take the applying of conformal coating into consideration so that the aforementioned requirement can be met. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 36 · page 36 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00213 | shall be specified in the initial offer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text shall be specified in the initial offer. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 36 · page 36 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00214 | The conformal coating process and materials shall apply to the latest versions of IPC/EIA J-STD-001 (with applicable standards as e.g.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-SYS-009 | Medium Proposal Ready Open point: - | DetailsFull requirement text The conformal coating process and materials shall apply to the latest versions of IPC/EIA J-STD-001 (with applicable standards as e.g. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-SYS-009 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 36 · page 36 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00215 | HDBK-001, IPC-CC-830 and HDBK-830) and the visual appearance of the final coating shall be consistent with the latest version of IPC-A-610.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text HDBK-001, IPC-CC-830 and HDBK-830) and the visual appearance of the final coating shall be consistent with the latest version of IPC-A-610. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 36 · page 36 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00216 | Water based and silicone lacquers shall not be used.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Low Proposal Ready Open point: - | DetailsFull requirement text Water based and silicone lacquers shall not be used. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 36 · page 36 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00217 | 7.45 Ventilation: The air inside the electronics enclosure shall be ventilated with the use of a membrane.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text 7.45 Ventilation: The air inside the electronics enclosure shall be ventilated with the use of a membrane. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 36 · page 36 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00218 | The following requirements shall be fulfilled: The unit shall withstand the salt-spray environment, according to CVS40 §6.1.6, without clogging of the membrane.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text The following requirements shall be fulfilled: The unit shall withstand the salt-spray environment, according to CVS40 §6.1.6, without clogging of the membrane. Engineering expectation Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 36 · page 36 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00219 | The membrane shall be placed so that it is protected against blunt force, falling dust and dripping salt-water.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text The membrane shall be placed so that it is protected against blunt force, falling dust and dripping salt-water. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 36 · page 36 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00220 | The design shall be made to prevent accumulation of water on top of the membrane, or in the cavity of the membrane.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text The design shall be made to prevent accumulation of water on top of the membrane, or in the cavity of the membrane. Engineering expectation Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 36 · page 36 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00221 | 7.46 Forbidden components: BGA capsule in any form must not be used.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Low Proposal Ready Open point: - | DetailsFull requirement text 7.46 Forbidden components: BGA capsule in any form must not be used. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 36 · page 36 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00222 | Tantalum capacitors must not be used Serial resistors on power supply circuits must not be used.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Low Proposal Ready Open point: - | DetailsFull requirement text Tantalum capacitors must not be used Serial resistors on power supply circuits must not be used. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 36 · page 36 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00223 | 8.3 The clutch actuator shall withstand 6 500 000 actuations with the test cycle described in Appendix B.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text 8.3 The clutch actuator shall withstand 6 500 000 actuations with the test cycle described in Appendix B. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 38 · page 38 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00224 | 8.4 Six consecutive units shall run past 6.5M actuations at the supplier, and continue to end of life.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-LIFE-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text 8.4 Six consecutive units shall run past 6.5M actuations at the supplier, and continue to end of life. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-LIFE-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 38 · page 38 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00225 | Three consecutive units shall run past 6.5M actuations at Scania, and continue to end of life.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-LIFE-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text Three consecutive units shall run past 6.5M actuations at Scania, and continue to end of life. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-LIFE-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 38 · page 38 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00226 | 8.5 The ECA must be maintenance free over the whole life time.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text 8.5 The ECA must be maintenance free over the whole life time. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 38 · page 38 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00227 | 8.6 Failure rate for ECU and electronics shall be less than: 0ppm @ “0” km 200ppm/year during year 1-5 400ppm/year during year 6-10 1000ppm/year during year 11-15 8.7 External vulnerable components might need to be replaceable.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Hardware platform support Architecture: Hardware Platform SSR: SSR-HW-001 | High Proposal Ready Open point: - | DetailsFull requirement text 8.6 Failure rate for ECU and electronics shall be less than: 0ppm @ “0” km 200ppm/year during year 1-5 400ppm/year during year 6-10 1000ppm/year during year 11-15 8.7 External vulnerable components might need to be replaceable. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-HW-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 38 · page 38 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00228 | Spare parts or repair kits shall be defined together in agreement.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-LIFE-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text Spare parts or repair kits shall be defined together in agreement. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-LIFE-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 38 · page 38 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00229 | 4.17) shall be provided as a spare part.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-LIFE-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text 4.17) shall be provided as a spare part. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-LIFE-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 38 · page 38 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00230 | 8.9 In a situation where the ECA has jammed, and is holding the clutch open, it shall be possible to remove the clutch force by following an instruction documented on the ECA drawing.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 8.9 In a situation where the ECA has jammed, and is holding the clutch open, it shall be possible to remove the clutch force by following an instruction documented on the ECA drawing. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 38 · page 38 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00231 | ID Recycling and environmental impact 9.1 The ECA shall fulfil the requirements stated in STD3868.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text ID Recycling and environmental impact 9.1 The ECA shall fulfil the requirements stated in STD3868. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 39 · page 39 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00232 | Out of a recycling and environmental perspective the following standards shall be taken under consideration in addition to CVS55(Ref 14.32): STD4158, Chemical substances which shall not be used – Scania Black list.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-003 | Low Proposal Ready Open point: - | DetailsFull requirement text Out of a recycling and environmental perspective the following standards shall be taken under consideration in addition to CVS55(Ref 14.32): STD4158, Chemical substances which shall not be used – Scania Black list. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-003 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 39 · page 39 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00233 | The different parts of the housing shall be marked according to material content.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text The different parts of the housing shall be marked according to material content. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 39 · page 39 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00234 | The ECA shall be lead free.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text The ECA shall be lead free. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 39 · page 39 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00235 | ID ADR Requirements 9.2 All included parts shall fulfil applicable sections of Part 9 in Annex B to the latest ADR ,as applicable at the time of type approval.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text ID ADR Requirements 9.2 All included parts shall fulfil applicable sections of Part 9 in Annex B to the latest ADR ,as applicable at the time of type approval. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 39 · page 39 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00236 | For type approval, the vehicle and its components shall comply with ECE Regulation No.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-004 | High Proposal Ready Open point: - | DetailsFull requirement text For type approval, the vehicle and its components shall comply with ECE Regulation No. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 39 · page 39 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00237 | P 1 Page 10 Environmental and electrical testing 10.1 The ECA must fulfil the general requirements for Electronic Control Units (ECUs), which are stated in CVS40 (Ref 14.1) and CVS41 (Ref 14.2).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text P 1 Page 10 Environmental and electrical testing 10.1 The ECA must fulfil the general requirements for Electronic Control Units (ECUs), which are stated in CVS40 (Ref 14.1) and CVS41 (Ref 14.2). Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 40 · page 40 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00238 | 10.2 The ECA must not be dependent on software for protection against requirements stated in CVS40 (Ref 14.1) and CVS41 (Ref 14.2).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Low Proposal Ready Open point: - | DetailsFull requirement text 10.2 The ECA must not be dependent on software for protection against requirements stated in CVS40 (Ref 14.1) and CVS41 (Ref 14.2). Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 40 · page 40 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00239 | CAN communication shall not be affected.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Low Proposal Ready Open point: - | DetailsFull requirement text CAN communication shall not be affected. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 40 · page 40 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00240 | Memory functions shall remain Class A.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Hardware platform support Architecture: Hardware Platform SSR: SSR-HW-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text Memory functions shall remain Class A. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-HW-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 40 · page 40 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00241 | Accepted behaviour in this case shall be agreed upon between Traton and Supplier.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text Accepted behaviour in this case shall be agreed upon between Traton and Supplier. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 40 · page 40 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00242 | P 1 Page 10.4 For this unit, the following definitions of test procedure I and test procedure II shall be used: Test procedure I A comprehensive test where all functional requirements are verified.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text P 1 Page 10.4 For this unit, the following definitions of test procedure I and test procedure II shall be used: Test procedure I A comprehensive test where all functional requirements are verified. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 41 · page 41 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00243 | This test shall be performed before and after exposure.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text This test shall be performed before and after exposure. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 41 · page 41 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00244 | Test procedure I (See Figure 17Test procedure I) shall at least contain: - Full stroke to evaluate speed - Staircase to evaluate accuracy - Power loss to evaluate safety Figure 17 - Test procedure I Test procedure II A reduced function test where the fundamental requirements are verified.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text Test procedure I (See Figure 17 - Test procedure I) shall at least contain: - Full stroke to evaluate speed - Staircase to evaluate accuracy - Power loss to evaluate safety Figure 17 - Test procedure I Test procedure II A reduced function test where the fundamental requirements are verified. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 41 · page 41 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00245 | This test shall be possible to perform during exposure.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text This test shall be possible to perform during exposure. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 41 · page 41 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00246 | Reduced versions of test procedure II may be agreed and used during various tests.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | Low Proposal Ready Open point: - | DetailsFull requirement text Reduced versions of test procedure II may be agreed and used during various tests. Engineering expectation Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 41 · page 41 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00247 | P 1 Page 10.5.11 CVS40 §5.5 TC-05 Temperature cycle test Tmax.tes= +120°C, Tmin.test=-40°C Y 10.5.12 CVS40 §5.6 TC-06 Thermal shock Y 10.5.13 CVS40 §5.7 TC-07 Splash water test Y 10.5.14 CVS40 §5.8 TC-08 Ice water / hot air shock test It is not allowed to use a snorkel to pass this test Y 10.5.15 CVS40 §5.9 TC-09 Leakage search test Y 10.5.16 CVS40 §5.10 TC-10 Ingress protection The ECA shall also fulfil IP54 without mounted connectors.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Low Proposal Ready Open point: - | DetailsFull requirement text P 1 Page 10.5.11 CVS40 §5.5 TC-05 Temperature cycle test Tmax.tes= +120°C, Tmin.test=-40°C Y 10.5.12 CVS40 §5.6 TC-06 Thermal shock Y 10.5.13 CVS40 §5.7 TC-07 Splash water test Y 10.5.14 CVS40 §5.8 TC-08 Ice water / hot air shock test It is not allowed to use a snorkel to pass this test Y 10.5.15 CVS40 §5.9 TC-09 Leakage search test Y 10.5.16 CVS40 §5.10 TC-10 Ingress protection The ECA shall also fulfil IP54 without mounted connectors. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 43 · page 43 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Medium, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00248 | tab headers) shall be made of self- extinguishing materials (i.e.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text tab headers) shall be made of self- extinguishing materials (i.e. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 44 · page 44 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00249 | P 1 Page 10.7.14 CVS46 §4.6.6 Test LFM: Low Frequency Magnetic Y 10.7.15 CVS46 §4.7 Test VCB CTE N 10.7.16 CVS46 §4.8 Test VCB AN and VCB CP N 10.7.17 CVS46 §4.9 Test C-VCB-VCA N 10.7.18 CVS46 §4.10 Test TSUP VCB A N 10.7.19 CVS46 §4.11 Test TSUP VCB B N 10.7.20 CVS46 §4.12 Test VCB Surge N 10.7.21 CVS46 §4.13 Test VCB Burst N 10.7.22 CVS46 §4.14 Test VCB Charging mode N 10.7.23 CVS46 §4.15 Test ESD: Immunity to electrostatic discharge (ESD) Y 10.7.24 CVS46 §4.15.1 Test ESDD: Direct Discharge, Powered up Y 10.7.25 CVS46 §4.15.2 Test ESDI: Indirect Discharge (Powered up) Y 10.7.26 CVS46 §4.15.3 Test ESDH: ESD Handling, Component not energised Y 10.7.27 CVS46 §5.1 Vehicle test ESD Traton performs Vehicle test, Traton may need support from supplier with any issues originating from the component.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | High Proposal Ready Open point: - | DetailsFull requirement text P 1 Page 10.7.14 CVS46 §4.6.6 Test LFM: Low Frequency Magnetic Y 10.7.15 CVS46 §4.7 Test VCB CTE N 10.7.16 CVS46 §4.8 Test VCB AN and VCB CP N 10.7.17 CVS46 §4.9 Test C-VCB-VCA N 10.7.18 CVS46 §4.10 Test TSUP VCB A N 10.7.19 CVS46 §4.11 Test TSUP VCB B N 10.7.20 CVS46 §4.12 Test VCB Surge N 10.7.21 CVS46 §4.13 Test VCB Burst N 10.7.22 CVS46 §4.14 Test VCB Charging mode N 10.7.23 CVS46 §4.15 Test ESD: Immunity to electrostatic discharge (ESD) Y 10.7.24 CVS46 §4.15.1 Test ESDD: Direct Discharge, Powered up Y 10.7.25 CVS46 §4.15.2 Test ESDI: Indirect Discharge (Powered up) Y 10.7.26 CVS46 §4.15.3 Test ESDH: ESD Handling, Component not energised Y 10.7.27 CVS46 §5.1 Vehicle test ESD Traton performs Vehicle test, Traton may need support from supplier with any issues originating from the component. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Architecture driver (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 47 · page 47 Estimation / resource / tool / IT / hardware impact Effort High, Competence Low, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00250 | Y 10.7.28 CVS46 §5.2 Vehicle test RE: Emitted interference of the complete vehicle Y 10.7.29 CVS46 §5.2.1 Vehicle test RE: Protection of receivers outside the vehicle Y 10.7.30 CVS46 §5.2.2 Vehicle test RE: Self- interference Y 10.7.31 CVS46 §5.3 Vehicle test charging: Vehicle in the AC charging mode N 10.7.32 CVS46 §5.3.1 Vehicle test: AC charging: Vehicle in AC charging mode N 10.7.33 CVS46 §5.3.2 Vehicle test: DC charging: Vehicle in DC charging mode N 10.7.34 CVS46 §5.4 Vehicle test RI: Immunity of vehicles to radiated fields Traton performs Vehicle test, Traton may need support from supplier with Y 10.7.35 CVS46 §5.4.1 Vehicle test RI: External interference sources YExpectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | Low Proposal Ready Open point: - | DetailsFull requirement text Y 10.7.28 CVS46 §5.2 Vehicle test RE: Emitted interference of the complete vehicle Y 10.7.29 CVS46 §5.2.1 Vehicle test RE: Protection of receivers outside the vehicle Y 10.7.30 CVS46 §5.2.2 Vehicle test RE: Self- interference Y 10.7.31 CVS46 §5.3 Vehicle test charging: Vehicle in the AC charging mode N 10.7.32 CVS46 §5.3.1 Vehicle test: AC charging: Vehicle in AC charging mode N 10.7.33 CVS46 §5.3.2 Vehicle test: DC charging: Vehicle in DC charging mode N 10.7.34 CVS46 §5.4 Vehicle test RI: Immunity of vehicles to radiated fields Traton performs Vehicle test, Traton may need support from supplier with Y 10.7.35 CVS46 §5.4.1 Vehicle test RI: External interference sources Y Engineering expectation Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 47 · page 47 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00251 | P 1 Page 11 Functional safety The ECA is a part of a safety critical system and shall be handled as such.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text P 1 Page 11 Functional safety The ECA is a part of a safety critical system and shall be handled as such. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 49 · page 49 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00252 | The ECA shall therefore be developed and implemented in accordance with the objectives and requirements of ISO 26262 "Road vehicles - Functional Safety".Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-SYS-009 | Medium Proposal Ready Open point: - | DetailsFull requirement text The ECA shall therefore be developed and implemented in accordance with the objectives and requirements of ISO 26262 "Road vehicles - Functional Safety". Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-SYS-009 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 49 · page 49 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00253 | The supplier shall analyse risks of individua l HW and SW components, mechanics, and any other technologies, independently of the scope of ISO 26262.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: Compliance Process; OEM/Customer Review Interface SSR: SSR-SYS-009 | High Proposal Ready Open point: - | DetailsFull requirement text The supplier shall analyse risks of individua l HW and SW components, mechanics, and any other technologies, independently of the scope of ISO 26262. Engineering expectation Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Compliance Process; OEM/Customer Review Interface | Work product: DIA / cybersecurity case | SSR: SSR-SYS-009 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 49 · page 49 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00254 | For this purpose possible causes must be systematically identified.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text For this purpose possible causes must be systematically identified. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 49 · page 49 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00255 | For these analyses at least the methods in ISO 26262 shall be applied.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-SYS-009 | Medium Proposal Ready Open point: - | DetailsFull requirement text For these analyses at least the methods in ISO 26262 shall be applied. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-SYS-009 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 49 · page 49 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00256 | ID Verification methods 12.1 Conformance to Requirement Specification A1 The supplier must do conformance test of all external and internal I/O.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Security evidence and traceability / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-VV-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text ID Verification methods 12.1 Conformance to Requirement Specification A1 The supplier must do conformance test of all external and internal I/O. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-VV-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 50 · page 50 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00257 | This test must verify that all internal and external I/O fulfils the requirements in this specification.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text This test must verify that all internal and external I/O fulfils the requirements in this specification. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 50 · page 50 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00258 | A2 The supplier must perform full DV (Design Verification at B-sample level) and full PV (Product Validation at C-sample level) environmental test programs according to CVS40 and CVS41 (incl.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Security evidence and traceability / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-VV-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text A2 The supplier must perform full DV (Design Verification at B-sample level) and full PV (Product Validation at C-sample level) environmental test programs according to CVS40 and CVS41 (incl. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-VV-001 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 50 · page 50 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00259 | the suppler must carry out two full test rounds according to the Traton test requirements.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text the suppler must carry out two full test rounds according to the Traton test requirements. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 50 · page 50 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00260 | Additional tests initiated and performed by the supplier must be discussed with Traton.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text Additional tests initiated and performed by the supplier must be discussed with Traton. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 50 · page 50 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00261 | A3 The supplier must test the connectors according to TB1787.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text A3 The supplier must test the connectors according to TB1787. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 50 · page 50 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00262 | A4 The supplier must do EMC tests with the unit alone.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text A4 The supplier must do EMC tests with the unit alone. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 50 · page 50 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00263 | The supplier must certify the ECA according to UN ECE R10 (EMC), according to the latest revision with all amendments.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text The supplier must certify the ECA according to UN ECE R10 (EMC), according to the latest revision with all amendments. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 50 · page 50 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00264 | A5 The supplier must check that both prototypes and serial units fulfil the dimension requirement according to any relevant Traton supplied drawings.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text A5 The supplier must check that both prototypes and serial units fulfil the dimension requirement according to any relevant Traton supplied drawings. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 50 · page 50 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00265 | A6 All prototypes and serial ECA’s shall fulfil requirements according to TB1822, IPC/EIA J-STD-001 class 3 and IPC-A-610 class 3.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text A6 All prototypes and serial ECA’s shall fulfil requirements according to TB1822, IPC/EIA J-STD-001 class 3 and IPC-A-610 class 3. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 50 · page 50 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00266 | 12.3 Testability The supplier of the unit must write software to enable his own testing of the unit during development, production and on any claimed unit.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior / OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text 12.3 Testability The supplier of the unit must write software to enable his own testing of the unit during development, production and on any claimed unit. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Application Software; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 50 · page 50 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00267 | However, dividing sample phases into several generations must be agreed upon between Traton and the supplier.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text However, dividing sample phases into several generations must be agreed upon between Traton and the supplier. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 51 · page 51 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00268 | All samples shall be functionally tested before sent to Traton.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text All samples shall be functionally tested before sent to Traton. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 51 · page 51 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00269 | Deviations shall be reported as a part of the sample delivery.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text Deviations shall be reported as a part of the sample delivery. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 51 · page 51 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00270 | Dimensional checks shall be performed for B and C-samples prior to delivery to Traton.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text Dimensional checks shall be performed for B and C-samples prior to delivery to Traton. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 51 · page 51 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00271 | The supplier must use the sample denominations requested by Traton.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text The supplier must use the sample denominations requested by Traton. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 51 · page 51 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00272 | Unless otherwise stated, valid version is the latest available as of 1st May 2026.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | Low Proposal Ready Open point: - | DetailsFull requirement text Unless otherwise stated, valid version is the latest available as of 1st May 2026. Engineering expectation Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 52 · page 52 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00273 | P 1 Page Appendix B – Life length test The life time testing of the ECA shall consist of 6500000 repetitions of the test cycle described in ”I – Test cycle” Two different test profiles/setups can be used.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text P 1 Page Appendix B – Life length test The life time testing of the ECA shall consist of 6500000 repetitions of the test cycle described in ”I – Test cycle” Two different test profiles/setups can be used. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 57 · page 57 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| req-5.1 | The full strokes should be performed within 180 ms, as specified in req 5.1 and 5.2.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Needs Internal Review | Needs internal review. Confirm whether this should-level requirement is in the committed baseline.Decision: Complete internal review of wording and baseline scope. | None | Feature / interface: System behavior Architecture: Compliance Process; System Core SSR: SSR-SYS-009 | Low Reviewed Internally Open point: - | DetailsFull requirement text The full strokes should be performed within 180 ms, as specified in req 5.1 and 5.2. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Needs internal review. Confirm whether this should-level requirement is in the committed baseline. Rationale Non-mandatory wording; baseline inclusion not yet confirmed. Implementation approach Decide baseline inclusion internally, then issue an Accept/Partial position. Acceptance condition Internal baseline decision recorded. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process; System Core | Work product: System/architecture design | SSR: SSR-SYS-009 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 57 · page 57 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Complete internal review of wording and baseline scope. |
| REQ-AUTO-00275 | Between the two movements the actuator should remain in the fully disengaged position.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Needs Internal Review | Needs internal review. Confirm whether this should-level requirement is in the committed baseline.Decision: Complete internal review of wording and baseline scope. | None | Feature / interface: System behavior Architecture: System Core SSR: None | Low Reviewed Internally Open point: - | DetailsFull requirement text Between the two movements the actuator should remain in the fully disengaged position. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Needs internal review. Confirm whether this should-level requirement is in the committed baseline. Rationale Non-mandatory wording; baseline inclusion not yet confirmed. Implementation approach Decide baseline inclusion internally, then issue an Accept/Partial position. Acceptance condition Internal baseline decision recorded. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 57 · page 57 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Complete internal review of wording and baseline scope. |
| REQ-AUTO-00276 | After the complete engagement the actuator should remain in this position until the next disengagement is requested.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Needs Internal Review | Needs internal review. Confirm whether this should-level requirement is in the committed baseline.Decision: Complete internal review of wording and baseline scope. | None | Feature / interface: System behavior Architecture: System Core SSR: None | Low Reviewed Internally Open point: - | DetailsFull requirement text After the complete engagement the actuator should remain in this position until the next disengagement is requested. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Needs internal review. Confirm whether this should-level requirement is in the committed baseline. Rationale Non-mandatory wording; baseline inclusion not yet confirmed. Implementation approach Decide baseline inclusion internally, then issue an Accept/Partial position. Acceptance condition Internal baseline decision recorded. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 57 · page 57 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Complete internal review of wording and baseline scope. |
| REQ-AUTO-00277 | • A function test rig shall be used for function tests between intervals • At 6.25M cycles a function test at -40C as well as the release frequency test is performed, before the rigs are put into run-to-failure mode • Run-to-failure mode implies cycling at intermediate load and RT/80C until failure • @Temp durability will start with 15/min frequency to verify if 30/min is feasible • One rig at RT shall run at 15/min as a reference unit for cycle acceleration.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text • A function test rig shall be used for function tests between intervals • At 6.25M cycles a function test at -40C as well as the release frequency test is performed, before the rigs are put into run-to-failure mode • Run-to-failure mode implies cycling at intermediate load and RT/80C until failure • @Temp durability will start with 15/min frequency to verify if 30/min is feasible • One rig at RT shall run at 15/min as a reference unit for cycle acceleration. Engineering expectation Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 59 · page 59 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00278 | This needs to be checked with the first test run and if necessary the test cycle used in profile B needs to be changed.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text This needs to be checked with the first test run and if necessary the test cycle used in profile B needs to be changed. Engineering expectation Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/3299216_1.md · 3299216_1 > Page 61 · page 61 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00279 | TRATON Software Update Variant 2 (SUV2) sequence Foreword This Commercial Vehicle Standard (“CVS123-2”) contains requirement specifications for TRATON Group and may be referred to by any of its commercial vehicle Affiliates.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: Secure software update and flash readiness Architecture: None SSR: None | High Proposal Ready Open point: - | DetailsFull requirement text TRATON Software Update Variant 2 (SUV2) sequence Foreword This Commercial Vehicle Standard (“CVS123-2”) contains requirement specifications for TRATON Group and may be referred to by any of its commercial vehicle Affiliates. Engineering expectation Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 1 · page 1 Estimation / resource / tool / IT / hardware impact Effort High, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00280 | Any review of this CVS123-2 shall only be done in agreement with the involved TRATON Group commercial vehicle Affiliates stated in the table below under section “Technical responsibility”.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-SYS-009 | Low Proposal Ready Open point: - | DetailsFull requirement text Any review of this CVS123-2 shall only be done in agreement with the involved TRATON Group commercial vehicle Affiliates stated in the table below under section “Technical responsibility”. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-SYS-009 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 1 · page 1 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00281 | The User shall apply the latest version of this CVS123-2.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text The User shall apply the latest version of this CVS123-2. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 1 · page 1 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00282 | SUV2_INFO 7 The reason to why an ECU must implement two or more diagnostic servers is that it needs to support two or more different ECU configurations: one for which no application is installed and one or more for which applications are installed in the ECU.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Diagnostic security | Feature / interface: Diagnostic security Architecture: Security Services SSR: SSR-RBAC-001 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text SUV2_INFO 7 The reason to why an ECU must implement two or more diagnostic servers is that it needs to support two or more different ECU configurations: one for which no application is installed and one or more for which applications are installed in the ECU. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Diagnostic security | Security capability: Diagnostic security | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 4 · page 4 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00283 | SUV2_INFO 8 It should be noted that a single server view is not completely achievable and that clients still need to be aware of two physical servers.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Needs Internal Review | Needs internal review. Confirm whether this should-level requirement is in the committed baseline.Decision: Complete internal review of wording and baseline scope. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: None | Low Reviewed Internally Open point: - | DetailsFull requirement text SUV2_INFO 8 It should be noted that a single server view is not completely achievable and that clients still need to be aware of two physical servers. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Needs internal review. Confirm whether this should-level requirement is in the committed baseline. Rationale Non-mandatory wording; baseline inclusion not yet confirmed. Implementation approach Decide baseline inclusion internally, then issue an Accept/Partial position. Acceptance condition Internal baseline decision recorded. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 4 · page 4 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Complete internal review of wording and baseline scope. |
| REQ-AUTO-00284 | Clients may prefer to implement programming support using other service parameter values or even another set of programming steps thanExpectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: Secure software update and flash readiness Architecture: None SSR: None | Low Proposal Ready Open point: - | DetailsFull requirement text Clients may prefer to implement programming support using other service parameter values or even another set of programming steps than Engineering expectation Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 4 · page 4 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00285 | For this reason, only the server is required to support the specified sequence.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Low Proposal Ready Open point: - | DetailsFull requirement text For this reason, only the server is required to support the specified sequence. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 5 · page 5 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00286 | Application data module (Calibration data) Contains a variant-specific set of parameter values that is required for correct operation of the control unit in a specific vehicle variant.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text Application data module (Calibration data) Contains a variant-specific set of parameter values that is required for correct operation of the control unit in a specific vehicle variant. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00287 | It must be clearly separated from the application software.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text It must be clearly separated from the application software. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00288 | For this reason, it is located in a separate memory area and must also be erasable and programmable independently of the application software.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text For this reason, it is located in a separate memory area and must also be erasable and programmable independently of the application software. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00289 | Application software module Contains all vehicle functions required for the normal server operation.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text Application software module Contains all vehicle functions required for the normal server operation. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00290 | All software parts required for the reprogramming like CAN driver, network layer, diagnostic services, boot operating system, start-up code, low level flash routines (for erasing, writing, reading), EEPROM access routines (read, write functionality), software compatibility checks etc.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | Diagnostic security | Feature / interface: Diagnostic security; Secure software update and flash readiness Architecture: Security Services SSR: SSR-RBAC-001 | High Proposal Ready Open point: - | DetailsFull requirement text All software parts required for the reprogramming like CAN driver, network layer, diagnostic services, boot operating system, start-up code, low level flash routines (for erasing, writing, reading), EEPROM access routines (read, write functionality), software compatibility checks etc. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Diagnostic security; Secure software update and flash readiness | Security capability: Diagnostic security | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00291 | shall be implemented in the boot software code.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text shall be implemented in the boot software code. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00292 | The value of this variable (and C2, see below) may be used by the boot manager to determine whether to start the application or the boot loader.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | Low Proposal Ready Open point: - | DetailsFull requirement text The value of this variable (and C2, see below) may be used by the boot manager to determine whether to start the application or the boot loader. Engineering expectation Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0051 | Internal Page 26 (90) Diagnostics Service Diag Safe state check Application Boot loader TransferData (0x36) MRequestFileTransfer (0x38) M - C1 = Mandatory except for going to default session C2 = Based on recommendation from Safety Team C3 = Needs to be defined at each individual routines The server implementation shall comply with the following state diagram and the following state transition descriptions (P1 and P2 flags should be seen as implementation hints).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: Application software behavior; System behavior; Secure software update and flash readiness Architecture: Application Software SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text Internal Page 26 (90) Diagnostics Service Diag Safe state check Application Boot loader TransferData (0x36) M - RequestFileTransfer (0x38) M - C1 = Mandatory except for going to default session C2 = Based on recommendation from Safety Team C3 = Needs to be defined at each individual routines REQ_UDS 0051 The server implementation shall comply with the following state diagram and the following state transition descriptions (P1 and P2 flags should be seen as implementation hints). Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; System behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Medium, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00294 | The value of this variable (and C1, see above) may be used by the boot manager to determine whether or not to start the application or the boot loader.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | Low Proposal Ready Open point: - | DetailsFull requirement text The value of this variable (and C1, see above) may be used by the boot manager to determine whether or not to start the application or the boot loader. Engineering expectation Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0051 | Internal Page 26 (90) Diagnostics Service Diag Safe state check Application Boot loader TransferData (0x36) MRequestFileTransfer (0x38) M - C1 = Mandatory except for going to default session C2 = Based on recommendation from Safety Team C3 = Needs to be defined at each individual routines The server implementation shall comply with the following state diagram and the following state transition descriptions (P1 and P2 flags should be seen as implementation hints).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: Application software behavior; System behavior; Secure software update and flash readiness Architecture: Application Software SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text Internal Page 26 (90) Diagnostics Service Diag Safe state check Application Boot loader TransferData (0x36) M - RequestFileTransfer (0x38) M - C1 = Mandatory except for going to default session C2 = Based on recommendation from Safety Team C3 = Needs to be defined at each individual routines REQ_UDS 0051 The server implementation shall comply with the following state diagram and the following state transition descriptions (P1 and P2 flags should be seen as implementation hints). Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; System behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Medium, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00296 | The value of this variable may be used by the application to determine whether or not initialization is required.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text The value of this variable may be used by the application to determine whether or not initialization is required. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00297 | Satisfied programming precondition A programming precondition agreed between supplier and vehicle manufacturer which, together with other agreed programming preconditions, shall be fulfilled before an ECU is made eligible for programming.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Hardware platform support; Secure software update and flash readiness / OEM/Customer Review Interface Architecture: Hardware Platform; OEM/Customer Review Interface SSR: SSR-UPD-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text Satisfied programming precondition A programming precondition agreed between supplier and vehicle manufacturer which, together with other agreed programming preconditions, shall be fulfilled before an ECU is made eligible for programming. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support; Secure software update and flash readiness | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Hardware Platform; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-UPD-002 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 7 · page 7 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00298 | Tester System that controls functions such as test, inspection, monitoring, or diagnosis of an on-vehicle electronic control unit and may be dedicated to a specific type of operator (e.g., an off-board scan tool dedicated to garage mechanics, an off-board test tool dedicated to assembly plants, or an on-board tester) see (1) 3.2 Abbreviated terms Table 2: Abbreviated terms Abbreviation Description NRC Negative Response Code NR Negative Response APP Application software BLF Boot Loader Flash CDTCS Clear DTC Setting CF Consecutive Frame Def Default diagnostic session DIAG Changeable over diagnostics interface DID Data identifier DSC Data Security Container EMP Entity Management Protocol Ext Extended diagnostic session FF First Frame FLASH BOOT Boot loader module stored in flash memory FLASH DATA Data set module stored in flash memoryExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: Secure software update and flash readiness Architecture: None SSR: None | High Proposal Ready Open point: - | DetailsFull requirement text Tester System that controls functions such as test, inspection, monitoring, or diagnosis of an on-vehicle electronic control unit and may be dedicated to a specific type of operator (e.g., an off-board scan tool dedicated to garage mechanics, an off-board test tool dedicated to assembly plants, or an on-board tester) see (1) 3.2 Abbreviated terms Table 2: Abbreviated terms Abbreviation Description NRC Negative Response Code NR Negative Response APP Application software BLF Boot Loader Flash CDTCS Clear DTC Setting CF Consecutive Frame Def Default diagnostic session DIAG Changeable over diagnostics interface DID Data identifier DSC Data Security Container EMP Entity Management Protocol Ext Extended diagnostic session FF First Frame FLASH BOOT Boot loader module stored in flash memory FLASH DATA Data set module stored in flash memory Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Cybersecurity control (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: None | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 7 · page 7 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00299 | Page 9 4 General requirements SUV2_REQ 1 The implementation of the client and the server shall be compliant with (ISO14229-1:2020) and the Traton Specification on Unified diagnostic Service (UDS) requirements (CVS124) with the clarifications, extensions and exceptions stated in this specification.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Diagnostic security | Feature / interface: Diagnostic security Architecture: Security Services SSR: SSR-RBAC-001 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text Page 9 4 General requirements SUV2_REQ 1 The implementation of the client and the server shall be compliant with (ISO14229-1:2020) and the Traton Specification on Unified diagnostic Service (UDS) requirements (CVS124) with the clarifications, extensions and exceptions stated in this specification. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Diagnostic security | Security capability: Diagnostic security | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00300 | Requirements in (CVS124) which are not explicitly stated to apply to the application only (such as communication parameters) shall apply to the boot loader as well.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-BOOT-001 | Low Proposal Ready Open point: - | DetailsFull requirement text Requirements in (CVS124) which are not explicitly stated to apply to the application only (such as communication parameters) shall apply to the boot loader as well. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-BOOT-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00301 | SUV2_REQ 2 All deviations from this specification shall be agreed with the applicable vehicle manufacturer(s).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 2 All deviations from this specification shall be agreed with the applicable vehicle manufacturer(s). Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00302 | SUV2_REQ 3 The programming requirements in this specification shall apply to the programming of all kinds of software modules (application, application data and boot loader), unless explicitly otherwise stated.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior; Secure software update and flash readiness Architecture: Application Software SSR: SSR-BOOT-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 3 The programming requirements in this specification shall apply to the programming of all kinds of software modules (application, application data and boot loader), unless explicitly otherwise stated. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-BOOT-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00303 | SUV2_REQ 4 If as a deviation with respect to SUV2_REQ 3 an ECU will not support boot loader reprogramming, the boot loader SW shall be in a protected area of the memory.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Hardware platform support; Secure software update and flash readiness Architecture: Hardware Platform SSR: SSR-BOOT-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 4 If as a deviation with respect to SUV2_REQ 3 an ECU will not support boot loader reprogramming, the boot loader SW shall be in a protected area of the memory. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-BOOT-002 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00304 | A SW or HW protection mechanism shall be used to protect the software from being accidentally erased or overwritten.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text A SW or HW protection mechanism shall be used to protect the software from being accidentally erased or overwritten. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00305 | If the microcontroller supports HW protection, this shall be used.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text If the microcontroller supports HW protection, this shall be used. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00306 | SUV2_REQ 5 The server shall support programming of all application software and application data modules and any subset of such modules in a single sequence without any intermediate reset service requests.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior; Secure software update and flash readiness Architecture: Application Software SSR: SSR-UPD-003 | Medium Proposal Ready Open point: OP-004 | DetailsFull requirement text SUV2_REQ 5 The server shall support programming of all application software and application data modules and any subset of such modules in a single sequence without any intermediate reset service requests. Engineering expectation Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-004 Traceability Feature: Application software behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-UPD-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00307 | SUV2_REQ 6 Programming of a subset of modules may lead to that the consistency check at the end of a programming sequence fails but shall not lead to that those programmed modules need to be reprogrammed from the beginning.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Secure software update and flash readiness Architecture: System Core SSR: SSR-UPD-001 | Low Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 6 Programming of a subset of modules may lead to that the consistency check at the end of a programming sequence fails but shall not lead to that those programmed modules need to be reprogrammed from the beginning. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-UPD-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00308 | SUV2_REQ 7 Boot loader updating according to this specification shall be supported during development, from A-samples and onwards.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-BOOT-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 7 Boot loader updating according to this specification shall be supported during development, from A-samples and onwards. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-BOOT-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00309 | SUV2_REQ 8 A server shall be programmable according to this specification (i.e., not only using supplier tools) regardless of whether one or more DTCs are currently active, or one or more functions are currently degraded.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration / OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface SSR: SSR-DIAG-003 | Low Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 8 A server shall be programmable according to this specification (i.e., not only using supplier tools) regardless of whether one or more DTCs are currently active, or one or more functions are currently degraded. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Backend and IT Systems; OEM/Customer Review Interface | Work product: Requirement traceability record | SSR: SSR-DIAG-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00310 | SUV2_REQ 9 A server shall be programmable while integrated in the vehicle network and as a standalone server without further conditions and without further interventions by the diagnostic tester as per this specification.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Diagnostic security | Feature / interface: Diagnostic security Architecture: Security Services SSR: SSR-RBAC-001 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text SUV2_REQ 9 A server shall be programmable while integrated in the vehicle network and as a standalone server without further conditions and without further interventions by the diagnostic tester as per this specification. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Diagnostic security | Security capability: Diagnostic security | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00311 | Page 10 SUV2_REQ 10 The solution for maintaining/reorganizing data (EEPROM data, operational data, adaptive data etc.) before and after reprogramming of software modules shall be discussed and agreed with the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior; Secure software update and flash readiness / OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface SSR: SSR-UPD-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text Page 10 SUV2_REQ 10 The solution for maintaining/reorganizing data (EEPROM data, operational data, adaptive data etc.) before and after reprogramming of software modules shall be discussed and agreed with the vehicle manufacturer. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Secure software update and flash readiness | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Application Software; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-UPD-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00312 | 4.1 Documentation requirements SUV2_REQ 11 The supplier shall provide, for each committed software delivery, a document that describes the programming procedure together with any requirement exceptions and ECU specific behaviours.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior; Secure software update and flash readiness; Security evidence and traceability / OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface SSR: SSR-UPD-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text 4.1 Documentation requirements SUV2_REQ 11 The supplier shall provide, for each committed software delivery, a document that describes the programming procedure together with any requirement exceptions and ECU specific behaviours. Engineering expectation Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Secure software update and flash readiness; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Application Software; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-UPD-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00313 | SUV2_REQ 12 Normal and worst-case performance values shall be documented for: • Total time for the programming sequence (programming steps prefixed “P1Pro”, see section Programming step of phase #1 – Download of application software and data).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior; Secure software update and flash readiness Architecture: Application Software SSR: SSR-UPD-003 | Medium Proposal Ready Open point: OP-004 | DetailsFull requirement text SUV2_REQ 12 Normal and worst-case performance values shall be documented for: • Total time for the programming sequence (programming steps prefixed “P1Pro”, see section Programming step of phase #1 – Download of application software and data). Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-004 Traceability Feature: Application software behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-UPD-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00314 | SUV2_REQ 13 The supplier shall document the versioning concept for supplier specific DIDs.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 13 The supplier shall document the versioning concept for supplier specific DIDs. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00315 | 4.2 Software architecture requirements SUV2_REQ 14 System name (DID 0xF197), diagnostic address and bitrate shall be persisted in an application data module dedicated for boot parameters, referred to as “boot parameter module”.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | Diagnostic security | Feature / interface: Diagnostic security Architecture: Security Services SSR: SSR-RBAC-001 | High Proposal Ready Open point: - | DetailsFull requirement text 4.2 Software architecture requirements SUV2_REQ 14 System name (DID 0xF197), diagnostic address and bitrate shall be persisted in an application data module dedicated for boot parameters, referred to as “boot parameter module”. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Diagnostic security | Security capability: Diagnostic security | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00316 | When this module is programmed the parameter values in it shall override default parameter values persisted in the boot loader software module.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-BOOT-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text When this module is programmed the parameter values in it shall override default parameter values persisted in the boot loader software module. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-BOOT-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00317 | It should be possible to reuse the generic bootloader for future currently unknown purposes/applications without a need to create a new part number for the platform.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Needs Customer Clarification | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Send linked open point to the customer for decision. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: None | High Reviewed Internally Open point: OP-004 | DetailsFull requirement text It should be possible to reuse the generic bootloader for future currently unknown purposes/applications without a need to create a new part number for the platform. Engineering expectation Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Supplier proposal 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. Rationale Flagged customer_clarification_needed=yes during extraction. Implementation approach Hold implementation; raise an open point and a clarification question. Acceptance condition Customer answers the linked open point. Customer feedback - Customer decision - Customer clarification / open point Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort High, Competence Low, Tooling Low, IT High, HW/Test Low Risk if unresolved Scope and effort cannot be frozen; estimation carries an open assumption and downstream design may rework. Next action Send linked open point to the customer for decision. |
| REQ-AUTO-00318 | SUV2_REQ 15 When the boot loader software in an ECU has not yet been parameterized (a boot parameter module has not been programmed) the boot loader software shall apply project specific default values, typically: • diagnostic address 0xA7 • baud rate 500 kb/s • DID 0xF197Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | Diagnostic security | Feature / interface: Diagnostic security Architecture: Security Services SSR: SSR-RBAC-001 | High Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 15 When the boot loader software in an ECU has not yet been parameterized (a boot parameter module has not been programmed) the boot loader software shall apply project specific default values, typically: • diagnostic address 0xA7 • baud rate 500 kb/s • DID 0xF197 Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Diagnostic security | Security capability: Diagnostic security | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00319 | SUV2_REQ 16 Default values for EOL parameters shall be implemented in a dedicated application data module, referred to as “EOL parameters module”.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 16 Default values for EOL parameters shall be implemented in a dedicated application data module, referred to as “EOL parameters module”. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00320 | SUV2_REQ 17 The partitioning of the ECU software into modules shall be discussed and agreed with the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Application software behavior / OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 17 The partitioning of the ECU software into modules shall be discussed and agreed with the vehicle manufacturer. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Application Software; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00321 | 4.3 Software distribution requirements SUV2_REQ 19 A software released for integration test, production or service market shall be hashed so its integrity can be verified by the server.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DAI-003 | Medium Proposal Ready Open point: OP-008 | DetailsFull requirement text 4.3 Software distribution requirements SUV2_REQ 19 A software released for integration test, production or service market shall be hashed so its integrity can be verified by the server. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-008 Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DAI-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00322 | SUV2_REQ 20 Flash files delivered from the supplier shall never have to be modified by the vehicle manufacturer.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Secure software update and flash readiness / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-UPD-001 | High Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 20 Flash files delivered from the supplier shall never have to be modified by the vehicle manufacturer. Engineering expectation Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Secure software update and flash readiness | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-UPD-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Medium, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00323 | SUV2_REQ 182 The supplier shall deliver the necessary information to verify the integrity of the flash files.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Secure software update and flash readiness / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-UPD-001 | High Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 182 The supplier shall deliver the necessary information to verify the integrity of the flash files. Engineering expectation Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Secure software update and flash readiness | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-UPD-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Medium, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00324 | SUV2_INFO 129 In case the supplier delivers encrypted flash files to the vehicle manufacturer, the supplier should also provide the necessary information so the flash files can be verified as part of flash files update procedure.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces; Secure software update and flash readiness / External Interfaces; OEM/Customer Review Interface Architecture: External Interfaces; OEM/Customer Review Interface SSR: SSR-UPD-004 | High Proposal Ready Open point: - | DetailsFull requirement text SUV2_INFO 129 In case the supplier delivers encrypted flash files to the vehicle manufacturer, the supplier should also provide the necessary information so the flash files can be verified as part of flash files update procedure. Engineering expectation Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces; Secure software update and flash readiness | Security capability: None | Interface: External Interfaces; OEM/Customer Review Interface | Architecture: External Interfaces; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-UPD-004 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort High, Competence Low, Tooling Medium, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00325 | SUV2_REQ 21 Whether or not the ECU shall be delivered from the supplier to the vehicle manufacturer with a pre-programmed application and pre-programmed application data shall be discussed and agreed with the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior / OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 21 Whether or not the ECU shall be delivered from the supplier to the vehicle manufacturer with a pre-programmed application and pre-programmed application data shall be discussed and agreed with the vehicle manufacturer. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Application Software; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00326 | SUV2_INFO 130 Regardless of if the ECU will be delivered from the supplier with a pre-programmed application and application data, the corresponding flash files shall be possible to request by vehicle manufacturer to be able to perform software verification at any time in vehicle manufacturer production site.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior; Secure software update and flash readiness; Security evidence and traceability / OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface SSR: SSR-UPD-003 | High Proposal Ready Open point: - | DetailsFull requirement text SUV2_INFO 130 Regardless of if the ECU will be delivered from the supplier with a pre-programmed application and application data, the corresponding flash files shall be possible to request by vehicle manufacturer to be able to perform software verification at any time in vehicle manufacturer production site. Engineering expectation Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Secure software update and flash readiness; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Application Software; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-UPD-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00327 | SUV2_REQ 22 When the application module is pre-programmed by the supplier, ECU and software identifiers 0xF187 and 0xF188 shall be set to product specific vehicle manufacturer defined values.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior / OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 22 When the application module is pre-programmed by the supplier, ECU and software identifiers 0xF187 and 0xF188 shall be set to product specific vehicle manufacturer defined values. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Application Software; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00328 | Otherwise 0xF187 and 0xF188 shall be set to default values, see CVS124.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text Otherwise 0xF187 and 0xF188 shall be set to default values, see CVS124. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00329 | Page 12 5 Detailed programming sequence SUV2_REQ 23 Programmable servers shall support the full programming sequence described in this chapter.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: System behavior; Secure software update and flash readiness Architecture: System Core SSR: SSR-UPD-001 | Medium Proposal Ready Open point: OP-004 | DetailsFull requirement text Page 12 5 Detailed programming sequence SUV2_REQ 23 Programmable servers shall support the full programming sequence described in this chapter. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-004 Traceability Feature: System behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-UPD-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00330 | SUV2_REQ 24 Non-programmable servers shall support the pre-programming and post-programming steps of the programming sequence described in this chapter (phase 1 and 2).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: System behavior; Secure software update and flash readiness Architecture: System Core SSR: SSR-UPD-001 | Medium Proposal Ready Open point: OP-004 | DetailsFull requirement text SUV2_REQ 24 Non-programmable servers shall support the pre-programming and post-programming steps of the programming sequence described in this chapter (phase 1 and 2). Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-004 Traceability Feature: System behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-UPD-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00331 | SUV2_REQ 25 The programming sequence described in this chapter shall be supported when a valid application is present as well as when no valid application is present in the ECU.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior; Secure software update and flash readiness Architecture: Application Software SSR: SSR-BOOT-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 25 The programming sequence described in this chapter shall be supported when a valid application is present as well as when no valid application is present in the ECU. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-BOOT-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00332 | The full set of addressing modes, SPRMIB values and other parameter values that the server shall support for each service are specified with implementation requirements in CVS124.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text The full set of addressing modes, SPRMIB values and other parameter values that the server shall support for each service are specified with implementation requirements in CVS124. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00333 | SUV2_REQ 26 To enable access to diagnostic services in the programming sequence, an authentication sequence shall be performed between the client and the server by means of the Authentication 0x29 service.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Authentication | Feature / interface: Authentication; Secure software update and flash readiness Architecture: Security Services SSR: SSR-RBAC-002 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text SUV2_REQ 26 To enable access to diagnostic services in the programming sequence, an authentication sequence shall be performed between the client and the server by means of the Authentication 0x29 service. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Authentication; Secure software update and flash readiness | Security capability: Authentication | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-002 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00334 | SUV2_REQ 27 The server shall receive a diagnostic service authentication (0x29) with SubFunction deAuthenticate (0x00) message from the client to disable authorized access to diagnostic programming services after an update is considered fulfilled.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Authentication | Feature / interface: Authentication; Secure software update and flash readiness Architecture: Security Services SSR: SSR-RBAC-002 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text SUV2_REQ 27 The server shall receive a diagnostic service authentication (0x29) with SubFunction deAuthenticate (0x00) message from the client to disable authorized access to diagnostic programming services after an update is considered fulfilled. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Authentication; Secure software update and flash readiness | Security capability: Authentication | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-002 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00335 | SUV2_INFO 35 As example, the client may read certificate validity time and/or RBAC configuration file to verify if the appropriate entities are stored in the server.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | High Proposal Ready Open point: - | DetailsFull requirement text SUV2_INFO 35 As example, the client may read certificate validity time and/or RBAC configuration file to verify if the appropriate entities are stored in the server. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Cybersecurity control (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 14 · page 14 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00336 | SUV2_INFO 39 As example, the client may have identified that the RBAC configuration file requires update and perform the appropriate set to update the entities stored in the server.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | High Proposal Ready Open point: - | DetailsFull requirement text SUV2_INFO 39 As example, the client may have identified that the RBAC configuration file requires update and perform the appropriate set to update the entities stored in the server. Engineering expectation Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 14 · page 14 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00337 | Alternatively, it may be a client strategy to always update certain entities prior to a software update.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: Secure software update and flash readiness Architecture: None SSR: None | High Proposal Ready Open point: - | DetailsFull requirement text Alternatively, it may be a client strategy to always update certain entities prior to a software update. Engineering expectation Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 14 · page 14 Estimation / resource / tool / IT / hardware impact Effort High, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00338 | SUV2_INFO 52 Since Link Control is only applicable in production when no application has been programmed by the supplier, the application may return NRC 0x7F (serviceNotSupportedInActiveSession) to this service request and expect the client to proceed to the next step.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: Application software behavior / OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface SSR: None | Low Proposal Ready Open point: - | DetailsFull requirement text SUV2_INFO 52 Since Link Control is only applicable in production when no application has been programmed by the supplier, the application may return NRC 0x7F (serviceNotSupportedInActiveSession) to this service request and expect the client to proceed to the next step. Engineering expectation Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Constraint (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Application Software; OEM/Customer Review Interface | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 15 · page 15 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00339 | SUV2_REQ 28 For the server to verify the integrity of the software, the information to verify shall be available to the server before step P1Pro6: Routine Control (erase Memory).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DAI-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 28 For the server to verify the integrity of the software, the information to verify shall be available to the server before step P1Pro6: Routine Control (erase Memory). Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DAI-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 16 · page 16 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00340 | SUV2_REQ 29 If the SW to be updated is encrypted, decryption keys shall be available to the server before step P1Pro9.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | High Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 29 If the SW to be updated is encrypted, decryption keys shall be available to the server before step P1Pro9. Engineering expectation Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 16 · page 16 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00341 | SUV2_REQ 30 Before the server executes the TransferData service, the server shall check if the data received during RequestDownload requests needs to be decrypted before writing the received data to non-volatile memory.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SDT-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 30 Before the server executes the TransferData service, the server shall check if the data received during RequestDownload requests needs to be decrypted before writing the received data to non-volatile memory. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SDT-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 16 · page 16 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0051 | Internal Page 26 (90) Diagnostics Service Diag Safe state check Application Boot loader TransferData (0x36) MRequestFileTransfer (0x38) M - C1 = Mandatory except for going to default session C2 = Based on recommendation from Safety Team C3 = Needs to be defined at each individual routines The server implementation shall comply with the following state diagram and the following state transition descriptions (P1 and P2 flags should be seen as implementation hints).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: Application software behavior; System behavior; Secure software update and flash readiness Architecture: Application Software SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text Internal Page 26 (90) Diagnostics Service Diag Safe state check Application Boot loader TransferData (0x36) M - RequestFileTransfer (0x38) M - C1 = Mandatory except for going to default session C2 = Based on recommendation from Safety Team C3 = Needs to be defined at each individual routines REQ_UDS 0051 The server implementation shall comply with the following state diagram and the following state transition descriptions (P1 and P2 flags should be seen as implementation hints). Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; System behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 17 · page 17 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Medium, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00343 | SUV2_INFO 82 Implementation hint: The integrity information may contain parts of memory not programmed, regardless of this the server verifies the integrity according to the supplied information on SDSC, see 9.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | Low Proposal Ready Open point: - | DetailsFull requirement text SUV2_INFO 82 Implementation hint: The integrity information may contain parts of memory not programmed, regardless of this the server verifies the integrity according to the supplied information on SDSC, see 9. Engineering expectation Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Non-functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 19 · page 19 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT High, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00344 | SUV2_INFO 93 If the application was started, it checks if application initialization is required.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_INFO 93 If the application was started, it checks if application initialization is required. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 20 · page 20 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00345 | If so, the server performs the required checks/reorganization measures for the data structures (EEPROM data, operational data, adaptive data etc.), executes the self-test and stores event memory entries, default values, DIDs F1AB, F1AA, F1A9 etc.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Hardware platform support Architecture: Hardware Platform SSR: SSR-LOG-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text If so, the server performs the required checks/reorganization measures for the data structures (EEPROM data, operational data, adaptive data etc.), executes the self-test and stores event memory entries, default values, DIDs F1AB, F1AA, F1A9 etc. Engineering expectation Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-LOG-002 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 20 · page 20 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT High, HW/Test High Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00346 | SUV2_INFO 94 Implementation hint: The ECU application checks the reprogrammed flag (C3, see programming step P1Pro11) to see if application initialization is required.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior; Secure software update and flash readiness Architecture: Application Software SSR: SSR-UPD-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_INFO 94 Implementation hint: The ECU application checks the reprogrammed flag (C3, see programming step P1Pro11) to see if application initialization is required. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-UPD-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 20 · page 20 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00347 | SUV2_INFO 85 As example, the client may have identified that the new software requires an updated RBAC configuration file and therefore set the entity on the server via EMP.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-RBAC-004 | High Proposal Ready Open point: - | DetailsFull requirement text SUV2_INFO 85 As example, the client may have identified that the new software requires an updated RBAC configuration file and therefore set the entity on the server via EMP. Engineering expectation Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-RBAC-004 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 20 · page 20 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00348 | Page 21 6 Server reprogramming requirements 6.1 Requirements for servers to support programming SUV2_REQ 33 ECUs that will be programmed stand-alone at the vehicle manufacturer over DoCAN shall support 1 Mbit transfer speed.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration; Secure software update and flash readiness / OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface SSR: SSR-UPD-005 | Medium Proposal Ready Open point: OP-004 | DetailsFull requirement text Page 21 6 Server reprogramming requirements 6.1 Requirements for servers to support programming SUV2_REQ 33 ECUs that will be programmed stand-alone at the vehicle manufacturer over DoCAN shall support 1 Mbit transfer speed. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-004 Traceability Feature: Backend and IT integration; Secure software update and flash readiness | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Backend and IT Systems; OEM/Customer Review Interface | Work product: Requirement traceability record | SSR: SSR-UPD-005 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 21 · page 21 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00349 | SUV2_REQ 34 Whether or not the ECU shall support stand-alone programming at the vehicle manufacturer premises shall be discussed and agreed with the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Hardware platform support; Secure software update and flash readiness / OEM/Customer Review Interface Architecture: Hardware Platform; OEM/Customer Review Interface SSR: SSR-UPD-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 34 Whether or not the ECU shall support stand-alone programming at the vehicle manufacturer premises shall be discussed and agreed with the vehicle manufacturer. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support; Secure software update and flash readiness | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Hardware Platform; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-UPD-002 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 21 · page 21 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00350 | SUV2_REQ 35 A server that is running in the application shall respond with the same diagnostic address after a switch to boot.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Diagnostic security | Feature / interface: Diagnostic security Architecture: Security Services SSR: SSR-RBAC-001 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text SUV2_REQ 35 A server that is running in the application shall respond with the same diagnostic address after a switch to boot. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Diagnostic security | Security capability: Diagnostic security | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 21 · page 21 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00351 | SUV2_REQ 36 It shall be possible to downgrade server software modules as long as the programmed modules are compatible with each other and with the hardware configuration.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 36 It shall be possible to downgrade server software modules as long as the programmed modules are compatible with each other and with the hardware configuration. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 21 · page 21 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00352 | SUV2_REQ 37 Application software and application data modules shall be programmable in any order.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 37 Application software and application data modules shall be programmable in any order. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 21 · page 21 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00353 | SUV2_REQ 38 The server shall be able to update an individual module independently from any other module.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | High Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 38 The server shall be able to update an individual module independently from any other module. Engineering expectation Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 21 · page 21 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00354 | SUV2_REQ 39 If the performance requirements SUV2_REQ 62 or SUV2_REQ 63 cannot be met, a compression method shall be implemented.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 39 If the performance requirements SUV2_REQ 62 or SUV2_REQ 63 cannot be met, a compression method shall be implemented. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 21 · page 21 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00355 | SUV2_REQ 40 The LZSS algorithm with a dictionary size of 1 023 bytes or a newer compression/decompression method with a higher compression ratio shall be used as the compression/decompression algorithm.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 40 The LZSS algorithm with a dictionary size of 1 023 bytes or a newer compression/decompression method with a higher compression ratio shall be used as the compression/decompression algorithm. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 21 · page 21 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00356 | SUV2_REQ 41 The use of alternative compression/decompression algorithms shall be agreed with the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 41 The use of alternative compression/decompression algorithms shall be agreed with the vehicle manufacturer. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 21 · page 21 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00357 | SUV2_REQ 42 It shall be possible to program the same software version repeatedly.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 42 It shall be possible to program the same software version repeatedly. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 21 · page 21 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00358 | SUV2_REQ 43 If at startup the ECU hardware/software is consistent and a programming request is not pending, the boot manager shall start and execute the application.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior; Secure software update and flash readiness Architecture: Application Software SSR: SSR-UPD-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 43 If at startup the ECU hardware/software is consistent and a programming request is not pending, the boot manager shall start and execute the application. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-UPD-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 21 · page 21 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00359 | SUV2_REQ 44 Otherwise if at startup the ECU hardware/software is inconsistent the boot manager shall start and execute the boot loader and reset DIDs 0xF181, 0xF187 and 0xF188 and 0xF1A1 to default values.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-BOOT-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 44 Otherwise if at startup the ECU hardware/software is inconsistent the boot manager shall start and execute the boot loader and reset DIDs 0xF181, 0xF187 and 0xF188 and 0xF1A1 to default values. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-BOOT-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 21 · page 21 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00360 | SUV2_REQ 45 If at startup the boot manager starts and executes the application, the application shall read and apply the parameter values persisted in the boot parameter module.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 45 If at startup the boot manager starts and executes the application, the application shall read and apply the parameter values persisted in the boot parameter module. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 21 · page 21 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00361 | Otherwise if at startup the boot manager starts and executes the boot loader and a valid boot parameter module has been successfully programmed, the boot loader shall read and apply these parameter values from the boot parameter module.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-BOOT-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text Otherwise if at startup the boot manager starts and executes the boot loader and a valid boot parameter module has been successfully programmed, the boot loader shall read and apply these parameter values from the boot parameter module. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-BOOT-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 21 · page 21 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00362 | Otherwise if no boot parameter module has been successfully programmed, the boot loader shall apply the corresponding parameter values persisted in the boot loader module.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-BOOT-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text Otherwise if no boot parameter module has been successfully programmed, the boot loader shall apply the corresponding parameter values persisted in the boot loader module. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-BOOT-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 21 · page 21 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00363 | Page 22 SUV2_REQ 46 After reprogramming, the application shall store DIDs F1AB, F1AA, F1A9.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior; Secure software update and flash readiness Architecture: Application Software SSR: SSR-UPD-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text Page 22 SUV2_REQ 46 After reprogramming, the application shall store DIDs F1AB, F1AA, F1A9. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-UPD-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 22 · page 22 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00364 | SUV2_REQ 47 The technical implementation of the programming preconditions shall be agreed between the supplier and the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Secure software update and flash readiness / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-UPD-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 47 The technical implementation of the programming preconditions shall be agreed between the supplier and the vehicle manufacturer. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Secure software update and flash readiness | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-UPD-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 22 · page 22 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00365 | SUV2_REQ 48 A programmable server shall guarantee re-programmability within the normal operating voltage range specified by [11] for 24V systems or [12] for 12V systems.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 48 A programmable server shall guarantee re-programmability within the normal operating voltage range specified by [11] for 24V systems or [12] for 12V systems. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 22 · page 22 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00366 | SUV2_REQ 49 A server that is restarted for any reason or thrown back to DefaultSession due to lack of TesterPresent or unfulfilled preconditions shall always support programming from the start of the programming sequence (programming step P1Pre), i.e., shall not depend on any state from an interrupted programming sequence.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration; Secure software update and flash readiness Architecture: Backend and IT Systems SSR: SSR-UPD-005 | Low Proposal Ready Open point: OP-002 | DetailsFull requirement text SUV2_REQ 49 A server that is restarted for any reason or thrown back to DefaultSession due to lack of TesterPresent or unfulfilled preconditions shall always support programming from the start of the programming sequence (programming step P1Pre), i.e., shall not depend on any state from an interrupted programming sequence. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Backend and IT integration; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-UPD-005 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 22 · page 22 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Medium, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00367 | 6.1.1 Boot software description and requirements 6.1.1.1 Boot software general requirements SUV2_REQ 50 The server shall guarantee re-programmability in the event of error conditions during the programming process regardless of cause.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior; Secure software update and flash readiness Architecture: Application Software SSR: SSR-UPD-003 | Medium Proposal Ready Open point: OP-004 | DetailsFull requirement text 6.1.1 Boot software description and requirements 6.1.1.1 Boot software general requirements SUV2_REQ 50 The server shall guarantee re-programmability in the event of error conditions during the programming process regardless of cause. Engineering expectation Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-004 Traceability Feature: Application software behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-UPD-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 22 · page 22 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00368 | The causes specified in (ISO14229-1:2020) shall be regarded as examples.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text The causes specified in (ISO14229-1:2020) shall be regarded as examples. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 22 · page 22 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00369 | SUV2_REQ 51 The server shall be re-programmable (standalone and in the vehicle) regardless of whether the application and application data is valid or has been corrupted.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 51 The server shall be re-programmable (standalone and in the vehicle) regardless of whether the application and application data is valid or has been corrupted. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 22 · page 22 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00370 | 6.1.1.2 Boot software session requirements SUV2_REQ 52 Diagnostic services support shall be as per CVS124.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | Diagnostic security | Feature / interface: Diagnostic security Architecture: Security Services SSR: SSR-RBAC-001 | High Proposal Ready Open point: - | DetailsFull requirement text 6.1.1.2 Boot software session requirements SUV2_REQ 52 Diagnostic services support shall be as per CVS124. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Diagnostic security | Security capability: Diagnostic security | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 22 · page 22 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00371 | SUV2_REQ 53 Additionally, the services specified in Table 3 shall be supported.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 53 Additionally, the services specified in Table 3 shall be supported. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 22 · page 22 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00372 | Non-Def = Any other session than default diagnostic session 6.1.1.3 ECU Identification Data SUV2_REQ 55 ECU identification data support shall be as per CVS124.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | Diagnostic security | Feature / interface: Diagnostic security Architecture: Security Services SSR: SSR-RBAC-001 | High Proposal Ready Open point: - | DetailsFull requirement text Non-Def = Any other session than default diagnostic session 6.1.1.3 ECU Identification Data SUV2_REQ 55 ECU identification data support shall be as per CVS124. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Diagnostic security | Security capability: Diagnostic security | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 23 · page 23 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00373 | 6.1.1.4 Performance requirements SUV2_REQ 62 When programmed in the vehicle manufacturer’s production facility the total time for programming of all modules shall not exceed 90 seconds with the programming sequence described in chapter Programming phase #1 – Download of application software and/or application data (phase #1 and phase #2).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior; Secure software update and flash readiness / OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface SSR: SSR-UPD-003 | Low Proposal Ready Open point: OP-004 | DetailsFull requirement text 6.1.1.4 Performance requirements SUV2_REQ 62 When programmed in the vehicle manufacturer’s production facility the total time for programming of all modules shall not exceed 90 seconds with the programming sequence described in chapter Programming phase #1 – Download of application software and/or application data (phase #1 and phase #2). Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-004 Traceability Feature: Application software behavior; Secure software update and flash readiness | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Application Software; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-UPD-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 23 · page 23 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00374 | SUV2_INFO 106 This does not apply to ECUs for which all software modules are pre-programmed in supplier premises, even if a software update capability is required in vehicle manufacturer production premises, e.g., for bug fixing.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior; Secure software update and flash readiness / OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface SSR: SSR-UPD-003 | High Proposal Ready Open point: - | DetailsFull requirement text SUV2_INFO 106 This does not apply to ECUs for which all software modules are pre-programmed in supplier premises, even if a software update capability is required in vehicle manufacturer production premises, e.g., for bug fixing. Engineering expectation Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Secure software update and flash readiness | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Application Software; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-UPD-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 23 · page 23 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00375 | SUV2_REQ 63 When programmed in the workshop the total time for programming of all modules shall not exceed 10 minutes with the programming sequence described in chapter Programming phase #1 – Download of application software and/or application data (phase #1 and phase #2).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior; Secure software update and flash readiness Architecture: Application Software SSR: SSR-UPD-003 | Low Proposal Ready Open point: OP-004 | DetailsFull requirement text SUV2_REQ 63 When programmed in the workshop the total time for programming of all modules shall not exceed 10 minutes with the programming sequence described in chapter Programming phase #1 – Download of application software and/or application data (phase #1 and phase #2). Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-004 Traceability Feature: Application software behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-UPD-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 23 · page 23 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00376 | 6.1.1.4.1 Server routine access SUV2_REQ 64 The server shall support the routines specified in Table 4.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 6.1.1.4.1 Server routine access SUV2_REQ 64 The server shall support the routines specified in Table 4. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 23 · page 23 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00377 | 7 Diagnostic service requirements 7.1 RequestDownload (0x34) Service SUV2_REQ 65 If the most recent Erase Memory routine request in the current session was made with the addressAndLengthFormatIdentifier parameter set to value 0x00 the server shall start erasing the memory area specified with the RequestDownload request.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Diagnostic security | Feature / interface: Diagnostic security Architecture: Security Services SSR: SSR-RBAC-001 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text 7 Diagnostic service requirements 7.1 RequestDownload (0x34) Service SUV2_REQ 65 If the most recent Erase Memory routine request in the current session was made with the addressAndLengthFormatIdentifier parameter set to value 0x00 the server shall start erasing the memory area specified with the RequestDownload request. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Diagnostic security | Security capability: Diagnostic security | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 24 · page 24 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00378 | SUV2_INFO 107 In order to satisfy stability requirements, the erasing of the boot loader may require that the old boot loader is copied into another memory area before the boot loader memory is erased, see Annex A for an implementation hint.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | Low Proposal Ready Open point: - | DetailsFull requirement text SUV2_INFO 107 In order to satisfy stability requirements, the erasing of the boot loader may require that the old boot loader is copied into another memory area before the boot loader memory is erased, see Annex A for an implementation hint. Engineering expectation Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Non-functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 24 · page 24 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00379 | SUV2_REQ 66 If the most recent Erase Memory routine request in the current session was made with the addressAndLengthFormatIdentifier parameter set to value 0x00 the server shall reset the following identification DIDs to their default values: • If boot software download is requested, reset 0xF180, 0xF191 and 0xF187 to default values (some of the DIDs will be automatically erased as a consequence of erasing one or more modules).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 66 If the most recent Erase Memory routine request in the current session was made with the addressAndLengthFormatIdentifier parameter set to value 0x00 the server shall reset the following identification DIDs to their default values: • If boot software download is requested, reset 0xF180, 0xF191 and 0xF187 to default values (some of the DIDs will be automatically erased as a consequence of erasing one or more modules). Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 24 · page 24 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00380 | SUV2_REQ 67 Once the RequestDownload service has started, only services TesterPresent, ECUReset,TransferData and DiagnosticSessionControl shall be permitted until service RequestTransferExit has been called or until any of these services returns an error.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SDT-001 | High Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 67 Once the RequestDownload service has started, only services TesterPresent, ECUReset,TransferData and DiagnosticSessionControl shall be permitted until service RequestTransferExit has been called or until any of these services returns an error. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SDT-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 24 · page 24 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00381 | SUV2_REQ 68 If a non-permitted service is requested after the RequestDownload service has started and before RequestTransferExit has been called the server shall respond with NRC 0x24Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 68 If a non-permitted service is requested after the RequestDownload service has started and before RequestTransferExit has been called the server shall respond with NRC 0x24 Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 24 · page 24 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00382 | Page 25 (requestSequenceError) and shall accept programming to proceed from the state at which it was executing before this non-permitted service was requested.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior; Secure software update and flash readiness Architecture: Application Software SSR: SSR-UPD-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text Page 25 (requestSequenceError) and shall accept programming to proceed from the state at which it was executing before this non-permitted service was requested. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-UPD-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 25 · page 25 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00383 | SUV2_REQ 69 For each received RequestDownload request, the server shall check if there is a VerificationEntry match in SDSC.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration; Security evidence and traceability / OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface SSR: SSR-VV-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 69 For each received RequestDownload request, the server shall check if there is a VerificationEntry match in SDSC. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Backend and IT Systems; OEM/Customer Review Interface | Work product: Requirement traceability record | SSR: SSR-VV-002 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 25 · page 25 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00384 | SUV2_REQ 71 The server shall check whether any part of the received data is encrypted or not by checking the address ranges for a match in EncryptionEntry defined in SDSC.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 71 The server shall check whether any part of the received data is encrypted or not by checking the address ranges for a match in EncryptionEntry defined in SDSC. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 25 · page 25 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00385 | SUV2_REQ 190 The server shall not execute the new software until it can be verified using routine 0xFF01.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Low Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 190 The server shall not execute the new software until it can be verified using routine 0xFF01. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 25 · page 25 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00386 | 7.1.1 Request SUV2_REQ 72 The server shall support service request formatted according to Table 5.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text 7.1.1 Request SUV2_REQ 72 The server shall support service request formatted according to Table 5. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 25 · page 25 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00387 | Page 26 7.1.2 Positive Response SUV2_REQ 73 The server shall support service positive response formatted according to Table 6.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text Page 26 7.1.2 Positive Response SUV2_REQ 73 The server shall support service positive response formatted according to Table 6. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 26 · page 26 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00388 | #4 maxNumberOfBlockLength[] = [ byte #1 (MSB) byte #2 ] M 0x0000 – 0xFFFF 7.1.3 Negative Response SUV2_REQ 74 The server shall support service negative response as per ISO14229-1:2020.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text #4 maxNumberOfBlockLength[] = [ byte #1 (MSB) byte #2 ] M 0x0000 – 0xFFFF 7.1.3 Negative Response SUV2_REQ 74 The server shall support service negative response as per ISO14229-1:2020. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 26 · page 26 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00389 | 7.1.4 Service 0x34 Parameters SUV2_REQ 165 In case a software is encrypted, the server shall decrypt the software before decompression and software hash comparison verification are performed.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior; Security evidence and traceability / OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface SSR: SSR-VV-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text 7.1.4 Service 0x34 Parameters SUV2_REQ 165 In case a software is encrypted, the server shall decrypt the software before decompression and software hash comparison verification are performed. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Application Software; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-VV-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 26 · page 26 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00390 | SUV2_REQ 166 In case a software is compressed, the server shall decompress the software before software hash comparison verification is performed.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior; Security evidence and traceability / OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface SSR: SSR-VV-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 166 In case a software is compressed, the server shall decompress the software before software hash comparison verification is performed. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Application Software; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-VV-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 26 · page 26 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00391 | SUV2_REQ 167 The server shall verify the software hash after decryption and/or decompression are performed.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 167 The server shall verify the software hash after decryption and/or decompression are performed. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 26 · page 26 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00392 | 7.1.4.1 Parameter dataFormatIdentifier SUV2_REQ 75 The server shall support parameter dataFormatIdentifier formatted according to Table 7.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 7.1.4.1 Parameter dataFormatIdentifier SUV2_REQ 75 The server shall support parameter dataFormatIdentifier formatted according to Table 7. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 26 · page 26 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00393 | Page 27 7.1.4.2 Parameter addressAndLengthFormatIdentifier SUV2_REQ 76 The server shall support parameter addressAndLengthFormatIdentifier formatted according to Table 8.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text Page 27 7.1.4.2 Parameter addressAndLengthFormatIdentifier SUV2_REQ 76 The server shall support parameter addressAndLengthFormatIdentifier formatted according to Table 8. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 27 · page 27 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00394 | Table 8: Service 0x34 addressAndLengthFormatIdentifier Format Bits Description Cvt Values 74 Length (number of bytes) of the memorySize parameter M 3,4 3 - 0 Length (number of bytes) of the memoryAddress parameter M 3, 4 7.1.4.3 Parameter lengthFormatIdentifier SUV2_REQ 77 The server shall support parameter lengthFormatIdentifier formatted according to Table 9.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text Table 8: Service 0x34 addressAndLengthFormatIdentifier Format Bits Description Cvt Values 7 - 4 Length (number of bytes) of the memorySize parameter M 3,4 3 - 0 Length (number of bytes) of the memoryAddress parameter M 3, 4 7.1.4.3 Parameter lengthFormatIdentifier SUV2_REQ 77 The server shall support parameter lengthFormatIdentifier formatted according to Table 9. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 27 · page 27 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00395 | M 0 7.2 TransferData (0x36) Service 7.2.1 Request SUV2_REQ 78 The server shall support request formatted according to ISO14229-1:2020.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SDT-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text M 0 7.2 TransferData (0x36) Service 7.2.1 Request SUV2_REQ 78 The server shall support request formatted according to ISO14229-1:2020. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SDT-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 27 · page 27 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00396 | 7.2.2 Positive Response SUV2_REQ 79 The server shall support positive response formatted according to ISO14229-1:2020.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 7.2.2 Positive Response SUV2_REQ 79 The server shall support positive response formatted according to ISO14229-1:2020. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 27 · page 27 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00397 | 7.2.3 Negative Response SUV2_REQ 80 SUV2_REQ 81 If for any reason an error occurs during decryption of data, the server shall return NRC 0x10.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 7.2.3 Negative Response SUV2_REQ 80 SUV2_REQ 81 If for any reason an error occurs during decryption of data, the server shall return NRC 0x10. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 27 · page 27 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00398 | 7.2.4 Service 0x36 Parameters 7.2.4.1 Parameter blockSequenceCounter SUV2_REQ 82 The server shall support parameter blockSequenceCounter formatted according to ISO14229-1:2020.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SDT-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 7.2.4 Service 0x36 Parameters 7.2.4.1 Parameter blockSequenceCounter SUV2_REQ 82 The server shall support parameter blockSequenceCounter formatted according to ISO14229-1:2020. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SDT-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 27 · page 27 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00399 | Page 28 7.2.4.2 Parameter transferRequestParameterRecord SUV2_REQ 83 The server shall support parameter transferRequestParameterRecord formatted according to ISO14229-1:2020.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text Page 28 7.2.4.2 Parameter transferRequestParameterRecord SUV2_REQ 83 The server shall support parameter transferRequestParameterRecord formatted according to ISO14229-1:2020. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 28 · page 28 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00400 | 7.3 RequestTransferExit (0x37) Service 7.3.1 Request SUV2_REQ 84 The server shall support request formatted according to Table 10.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text 7.3 RequestTransferExit (0x37) Service 7.3.1 Request SUV2_REQ 84 The server shall support request formatted according to Table 10. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 28 · page 28 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00401 | Table 10: Service 0x37 Request Format Byte No Description Cvt Byte Value 1 RequestTransferExit Request SID M 0x37 7.3.2 Positive Response SUV2_REQ 85 The server shall support positive response formatted according to Table 11.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text Table 10: Service 0x37 Request Format Byte No Description Cvt Byte Value 1 RequestTransferExit Request SID M 0x37 7.3.2 Positive Response SUV2_REQ 85 The server shall support positive response formatted according to Table 11. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 28 · page 28 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00402 | Table 11: Service 0x37 Positive Response Format Byte No Description Cvt Byte Value 1 RequestTransferExit Response SID M 0x77 7.3.3 Negative Response SUV2_REQ 86 7.3.4 Service 0x37 Parameters 7.3.4.1 Parameter transferRequestParameterRecord SUV2_REQ 87 The server shall not support transferRequestParameterRecord parameter.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Low Proposal Ready Open point: - | DetailsFull requirement text Table 11: Service 0x37 Positive Response Format Byte No Description Cvt Byte Value 1 RequestTransferExit Response SID M 0x77 7.3.3 Negative Response SUV2_REQ 86 7.3.4 Service 0x37 Parameters 7.3.4.1 Parameter transferRequestParameterRecord SUV2_REQ 87 The server shall not support transferRequestParameterRecord parameter. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 28 · page 28 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00403 | 7.3.4.2 Parameter transferResponseParameterRecord SUV2_REQ 88 The server shall not support transferResponseParameterRecord parameter.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Low Proposal Ready Open point: - | DetailsFull requirement text 7.3.4.2 Parameter transferResponseParameterRecord SUV2_REQ 88 The server shall not support transferResponseParameterRecord parameter. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 28 · page 28 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00404 | 7.4 SecuredDataTranmission (0x84) Service SUV2_REQ 89 The server shall support service 0x84 according to CVS32.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text 7.4 SecuredDataTranmission (0x84) Service SUV2_REQ 89 The server shall support service 0x84 according to CVS32. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 28 · page 28 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00405 | 7.4.1 Request SUV2_REQ 90 The server shall support request formatted according to ISO14229-1:2020.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 7.4.1 Request SUV2_REQ 90 The server shall support request formatted according to ISO14229-1:2020. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 28 · page 28 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00406 | Page 29 7.4.2 Positive Response SUV2_REQ 91 The server shall support positive response formatted according to ISO14229-1:2020.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text Page 29 7.4.2 Positive Response SUV2_REQ 91 The server shall support positive response formatted according to ISO14229-1:2020. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 29 · page 29 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00407 | 7.4.3 Negative Response SUV2_REQ 92 SUV2_REQ 93 The server shall support negative response codes according to CVS32.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 7.4.3 Negative Response SUV2_REQ 92 SUV2_REQ 93 The server shall support negative response codes according to CVS32. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 29 · page 29 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00408 | 7.4.4 Service 0x84 Parameters 7.4.4.1 Parameter Administrative Parameter SUV2_REQ 94 The server shall support parameter Administrative Parameter formatted according to ISO14229-1:2020.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text 7.4.4 Service 0x84 Parameters 7.4.4.1 Parameter Administrative Parameter SUV2_REQ 94 The server shall support parameter Administrative Parameter formatted according to ISO14229-1:2020. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 29 · page 29 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00409 | 7.4.4.2 Parameter Signature/Encryption Calculation (SIGENCRYPT) SUV2_REQ 95 The server shall support parameter Signature/Encryption Calculation (SIGENCRYPT) according to CVS32.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-DAI-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text 7.4.4.2 Parameter Signature/Encryption Calculation (SIGENCRYPT) SUV2_REQ 95 The server shall support parameter Signature/Encryption Calculation (SIGENCRYPT) according to CVS32. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-DAI-004 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 29 · page 29 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00410 | 7.4.4.3 Parameter Anti-replay Counter (ANTIREPLAYCNT) SUV2_REQ 96 The server shall support parameter Anti-replay Counter (ANTIREPLAYCNT) according to CVS32.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Secure communication and freshness protection; Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-006 | Medium Proposal Ready Open point: - | DetailsFull requirement text 7.4.4.3 Parameter Anti-replay Counter (ANTIREPLAYCNT) SUV2_REQ 96 The server shall support parameter Anti-replay Counter (ANTIREPLAYCNT) according to CVS32. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Secure communication and freshness protection; Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-006 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 29 · page 29 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00411 | 8 Diagnostic Routine Identifier Requirements 8.1 Routine Session and routineControlSupport 8.1.1 Routine Session Support SUV2_REQ 97 The server shall support the routine in the diagnosticSession according to Table 12.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Diagnostic security | Feature / interface: Diagnostic security Architecture: Security Services SSR: SSR-RBAC-001 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text 8 Diagnostic Routine Identifier Requirements 8.1 Routine Session and routineControlSupport 8.1.1 Routine Session Support SUV2_REQ 97 The server shall support the routine in the diagnosticSession according to Table 12. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Diagnostic security | Security capability: Diagnostic security | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 29 · page 29 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00412 | Non-Def = Any other session than default diagnostic session 8.1.2 Routine routineControlType Support SUV2_REQ 98 The server shall support the routineControlType according to Table 13.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Diagnostic security | Feature / interface: Diagnostic security Architecture: Security Services SSR: SSR-RBAC-001 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text Non-Def = Any other session than default diagnostic session 8.1.2 Routine routineControlType Support SUV2_REQ 98 The server shall support the routineControlType according to Table 13. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Diagnostic security | Security capability: Diagnostic security | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 30 · page 30 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00413 | Table 13: Routine Support per routineControlType RID Name routineControlType startRoutine (0x01) stopRoutine (0x02) requestRoutineResults (0x03) 0x2202 Check Memory Block M - - 0xFF00 EraseMemory M - - 0xFF01 CheckProgrammingDependencies M - - 0xCAFE Entity Management Protocol (EMP) M - - M = Mandatory 8.1.3 Routine Safe State Requirement SUV2_REQ 181 The server shall implement diagnostic safe state, as per CVS124, as preconditions to the routines according to Table 14.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Diagnostic security | Feature / interface: Diagnostic security; Secure software update and flash readiness Architecture: Security Services SSR: SSR-RBAC-001 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text Table 13: Routine Support per routineControlType RID Name routineControlType startRoutine (0x01) stopRoutine (0x02) requestRoutineResults (0x03) 0x2202 Check Memory Block M - - 0xFF00 EraseMemory M - - 0xFF01 CheckProgrammingDependencies M - - 0xCAFE Entity Management Protocol (EMP) M - - M = Mandatory 8.1.3 Routine Safe State Requirement SUV2_REQ 181 The server shall implement diagnostic safe state, as per CVS124, as preconditions to the routines according to Table 14. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Diagnostic security; Secure software update and flash readiness | Security capability: Diagnostic security | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 30 · page 30 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00414 | SUV2_REQ 99 The server shall verify the programmed software module by calculating a checksum on the programmed data by matching this checksum with a pre-calculated checksum.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DAI-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 99 The server shall verify the programmed software module by calculating a checksum on the programmed data by matching this checksum with a pre-calculated checksum. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DAI-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 30 · page 30 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00415 | SUV2_REQ 100 The pre-calculated checksum shall be provided as part of the data submitted with the TransferData service request.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SDT-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 100 The pre-calculated checksum shall be provided as part of the data submitted with the TransferData service request. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SDT-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 30 · page 30 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00416 | Page 31 SUV2_INFO 111 Implementation Hint: The following generator polynomial with the following initial value are suggested to be used for calculation of the checksum: G(X) = x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1 Initial value: 0xFFFFFFFF 8.2.1 Request SUV2_REQ 102 The server shall support the routine request according to Table 15.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-DAI-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text Page 31 SUV2_INFO 111 Implementation Hint: The following generator polynomial with the following initial value are suggested to be used for calculation of the checksum: G(X) = x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1 Initial value: 0xFFFFFFFF 8.2.1 Request SUV2_REQ 102 The server shall support the routine request according to Table 15. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-DAI-004 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 31 · page 31 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00417 | Table 15: Routine 0x2202 Request Format Byte Description Cvt Hex #1 RoutineControl Request SID M 0x31 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) M 0x22 #4 routineIdentifier (LSB) M 0x02 8.2.2 Positive Response SUV2_REQ 103 The server shall support the routine positive response according to Table 16.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-DIAG-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text Table 15: Routine 0x2202 Request Format Byte Description Cvt Hex #1 RoutineControl Request SID M 0x31 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) M 0x22 #4 routineIdentifier (LSB) M 0x02 8.2.2 Positive Response SUV2_REQ 103 The server shall support the routine positive response according to Table 16. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-DIAG-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 31 · page 31 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00418 | Page 32 8.2.4 Routine 0x2202 Parameters 8.2.4.1 Parameter routineStatus routineResult SUV2_REQ 105 The server shall support parameter routineStatus routineResult formatted according to Table 17.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-DIAG-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text Page 32 8.2.4 Routine 0x2202 Parameters 8.2.4.1 Parameter routineStatus routineResult SUV2_REQ 105 The server shall support parameter routineStatus routineResult formatted according to Table 17. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-DIAG-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 32 · page 32 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00419 | SUV2_REQ 106 The server shall respond with a positive response code without erasing memory if the specified memory area has already been completely erased (or is writable) at the time the service is requested.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 106 The server shall respond with a positive response code without erasing memory if the specified memory area has already been completely erased (or is writable) at the time the service is requested. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 32 · page 32 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00420 | SUV2_INFO 113 In order to satisfy stability requirements, the erasing of the boot loader may require that the current boot loader be copied into another non-volatile memory area before the boot loader memory is erased, see Annex A for an implementation hint.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | Low Proposal Ready Open point: - | DetailsFull requirement text SUV2_INFO 113 In order to satisfy stability requirements, the erasing of the boot loader may require that the current boot loader be copied into another non-volatile memory area before the boot loader memory is erased, see Annex A for an implementation hint. Engineering expectation Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Non-functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 32 · page 32 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00421 | SUV2_REQ 107 In case the non volatile memory area is currently hosting a bootloader copy, meaning there is an ongoing bootloader update procedure, the ECU shall ensure that this memory area shall not be erased until a valid bootloader is flashed in the bootloader memory area.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Hardware platform support; Secure software update and flash readiness Architecture: Hardware Platform SSR: SSR-BOOT-002 | High Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 107 In case the non volatile memory area is currently hosting a bootloader copy, meaning there is an ongoing bootloader update procedure, the ECU shall ensure that this memory area shall not be erased until a valid bootloader is flashed in the bootloader memory area. Engineering expectation Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-BOOT-002 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 32 · page 32 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Medium, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00422 | SUV2_REQ 108 When the addressAndLengthFormatIdentifier parameter is set to a value > 0x00 the server shall reset the following software and data identification DIDs to their default values (see section Software and data identification): • If boot software (any part) is erased, reset 0xF180, 0xF191 and 0xF187 to default values (some of the DIDs will be automatically erased as a consequence of erasing one or more modules).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-008 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 108 When the addressAndLengthFormatIdentifier parameter is set to a value > 0x00 the server shall reset the following software and data identification DIDs to their default values (see section Software and data identification): • If boot software (any part) is erased, reset 0xF180, 0xF191 and 0xF187 to default values (some of the DIDs will be automatically erased as a consequence of erasing one or more modules). Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-008 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 32 · page 32 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00423 | SUV2_REQ 109 The erasing of memory shall not prevent the client from starting a data transfer using the TransferData (0x36) service, i.e., the erasing of memory shall proceed in parallel with data transfer in case for ECUs implementing Automatic erase.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SDT-001 | Low Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 109 The erasing of memory shall not prevent the client from starting a data transfer using the TransferData (0x36) service, i.e., the erasing of memory shall proceed in parallel with data transfer in case for ECUs implementing Automatic erase. Engineering expectation Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SDT-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 32 · page 32 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00424 | Page 33 8.3.1 Routine Request SUV2_REQ 110 The server shall support the routine request according to Table 18.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text Page 33 8.3.1 Routine Request SUV2_REQ 110 The server shall support the routine request according to Table 18. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 33 · page 33 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00425 | 8.3.2 Routine Positive Response SUV2_REQ 111 The server shall support the routine positive response according to Table 19.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 8.3.2 Routine Positive Response SUV2_REQ 111 The server shall support the routine positive response according to Table 19. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 33 · page 33 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00426 | Page 34 8.3.3 Routine Negative Response SUV2_REQ 112 8.3.4 Routine 0xFF00 Parameters 8.3.4.1 Parameter addressAndLengthFormatIdentifier SUV2_REQ 113 The server shall support parameter addressAndLengthFormatIdentifier formatted according to Table 20.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text Page 34 8.3.3 Routine Negative Response SUV2_REQ 112 8.3.4 Routine 0xFF00 Parameters 8.3.4.1 Parameter addressAndLengthFormatIdentifier SUV2_REQ 113 The server shall support parameter addressAndLengthFormatIdentifier formatted according to Table 20. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 34 · page 34 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00427 | E.g., 02, Module 2 (Application SW module) M 0x02 – 0xFF Physical memory range erase: Refer to ISO 14229-1 Table H1 M C = Mandatory if required to meet the performance requirements SUV2_REQ 62 & SUV2_REQ 63.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-008 | Medium Proposal Ready Open point: - | DetailsFull requirement text E.g., 02, Module 2 (Application SW module) M 0x02 – 0xFF Physical memory range erase: Refer to ISO 14229-1 Table H1 M C = Mandatory if required to meet the performance requirements SUV2_REQ 62 & SUV2_REQ 63. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-008 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 34 · page 34 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00428 | SUV2_REQ 114 When the addressAndLengthFormatIdentifier is set to 0x01 the defined module to index mapping shall apply for the memoryStartAddress according to Table 21.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 114 When the addressAndLengthFormatIdentifier is set to 0x01 the defined module to index mapping shall apply for the memoryStartAddress according to Table 21. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 34 · page 34 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00429 | Table 21: Module to Index Mapping Value Mapped to 0x01 Bootloader 0x02 Application 0x03 Application Data 0x04 – 0xFF System Specific 8.3.4.2 Paramter routineStatus routineResult SUV2_REQ 115 The server shall support parameter routineStatus routineResult formatted according to Table 22.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-BOOT-001 | High Proposal Ready Open point: OP-004 | DetailsFull requirement text Table 21: Module to Index Mapping Value Mapped to 0x01 Bootloader 0x02 Application 0x03 Application Data 0x04 – 0xFF System Specific 8.3.4.2 Paramter routineStatus routineResult SUV2_REQ 115 The server shall support parameter routineStatus routineResult formatted according to Table 22. Engineering expectation Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-004 Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-BOOT-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 34 · page 34 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00430 | SUV2_REQ 143 This RoutineIdentifier shall be able to execute independent from programming sequence SUV2_INFO 124 The client may opt to execute this routineIdentifier as a standalone procedure to check to perform a software consistency check.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior; Secure software update and flash readiness Architecture: Application Software SSR: SSR-UPD-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 143 This RoutineIdentifier shall be able to execute independent from programming sequence SUV2_INFO 124 The client may opt to execute this routineIdentifier as a standalone procedure to check to perform a software consistency check. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-UPD-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 35 · page 35 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00431 | SUV2_REQ 116 The server shall check whether the individual modules are complete and compatible with one another.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 116 The server shall check whether the individual modules are complete and compatible with one another. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 35 · page 35 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00432 | In addition, a check shall be made to determine whether the software is compatible with the hardware version (e.g., variants of sensors/actuators) and other data structures (e.g., EEPROM data).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-008 | Medium Proposal Ready Open point: - | DetailsFull requirement text In addition, a check shall be made to determine whether the software is compatible with the hardware version (e.g., variants of sensors/actuators) and other data structures (e.g., EEPROM data). Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-008 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 35 · page 35 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00433 | SUV2_REQ 117 The method used to check compatibility/consistency shall be determined by the supplier in consultation with the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 117 The method used to check compatibility/consistency shall be determined by the supplier in consultation with the vehicle manufacturer. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 35 · page 35 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00434 | SUV2_REQ 118 The consistency check shall be carried out solely by the server.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 118 The consistency check shall be carried out solely by the server. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 35 · page 35 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00435 | SUV2_REQ 119 The server shall verify the integrity of the software as a part of the consistency check.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DAI-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 119 The server shall verify the integrity of the software as a part of the consistency check. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DAI-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 35 · page 35 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00436 | SUV2_REQ 120 The integrity information shall be supplied to the server before the software is updated.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DAI-003 | High Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 120 The integrity information shall be supplied to the server before the software is updated. Engineering expectation Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DAI-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 35 · page 35 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00437 | SUV2_REQ 121 The integrity check shall be carried out solely by the server.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-DAI-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 121 The integrity check shall be carried out solely by the server. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-DAI-004 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 35 · page 35 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00438 | 8.4.1 Request SUV2_REQ 122 The server shall support the routine request according to Table 23.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 8.4.1 Request SUV2_REQ 122 The server shall support the routine request according to Table 23. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 35 · page 35 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00439 | Page 36 8.4.2 Positive Response SUV2_REQ 123 The server shall support the routine positive response according to Table 24.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text Page 36 8.4.2 Positive Response SUV2_REQ 123 The server shall support the routine positive response according to Table 24. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 36 · page 36 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00440 | Table 24: Routine 0xFF01 Positive Response Format #1 RoutineControl Response SID M 0x71 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) checkProgrammingDependencies[byte#1] M 0xFF #4 routineIdentifier (LSB) checkProgrammingDependencies [byte#2] M 0x01 #5 routineStatus routineResult M 0x00-0xFF #6 … #7 routineResultProofLength M Uint16 #8 … #n routineResultProof M Uint8[] 8.4.3 Negative Response SUV2_REQ 124 8.4.4 Routine 0xFF01 Parameters 8.4.4.1 Parameter routineStatus routineResult SUV2_REQ 125 The server shall support parameter routineStatus routineResult formatted according to Table 25.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration; Secure software update and flash readiness Architecture: Backend and IT Systems SSR: SSR-UPD-005 | Medium Proposal Ready Open point: OP-004 | DetailsFull requirement text Table 24: Routine 0xFF01 Positive Response Format #1 RoutineControl Response SID M 0x71 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) checkProgrammingDependencies[byte#1] M 0xFF #4 routineIdentifier (LSB) checkProgrammingDependencies [byte#2] M 0x01 #5 routineStatus routineResult M 0x00-0xFF #6 … #7 routineResultProofLength M Uint16 #8 … #n routineResultProof M Uint8[] 8.4.3 Negative Response SUV2_REQ 124 8.4.4 Routine 0xFF01 Parameters 8.4.4.1 Parameter routineStatus routineResult SUV2_REQ 125 The server shall support parameter routineStatus routineResult formatted according to Table 25. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-004 Traceability Feature: Backend and IT integration; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-UPD-005 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 36 · page 36 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00441 | Table 25: Routine 0xFF01 routineStatus routineResult Format Hex Description Cvt 0x00 correctResult M 0x01 incorrectResult - General Failure M 0x02 incorrectResult error SW – HW M 0x03 incorrectResult error SW – SW M 0x04 IncorrectResult One or more modules are not programmed or are incorrectly programmed M 0x05 incorrectResult One or more modules failed when verifying the integrity of the software M 0x06 – 0xFF Reserved M SUV2_REQ 126 The server shall set routineResult as 0x00 (correctResult) if the integrity verification is valid, the software was successfully installed and the installed software are compatible between all software module and the software is compatible with the ECU hardware.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior; Security evidence and traceability / OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface SSR: SSR-DAI-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text Table 25: Routine 0xFF01 routineStatus routineResult Format Hex Description Cvt 0x00 correctResult M 0x01 incorrectResult - General Failure M 0x02 incorrectResult error SW – HW M 0x03 incorrectResult error SW – SW M 0x04 IncorrectResult One or more modules are not programmed or are incorrectly programmed M 0x05 incorrectResult One or more modules failed when verifying the integrity of the software M 0x06 – 0xFF Reserved M SUV2_REQ 126 The server shall set routineResult as 0x00 (correctResult) if the integrity verification is valid, the software was successfully installed and the installed software are compatible between all software module and the software is compatible with the ECU hardware. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Application Software; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-DAI-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 36 · page 36 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00442 | If the server set routineResult as 0x00 (CorrectResult) the server shall reject with NRC 0x24 the following diagnostic services and routines until a new SDSC is provided:Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Diagnostic security | Feature / interface: Diagnostic security Architecture: Security Services SSR: SSR-RBAC-001 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text If the server set routineResult as 0x00 (CorrectResult) the server shall reject with NRC 0x24 the following diagnostic services and routines until a new SDSC is provided: Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Diagnostic security | Security capability: Diagnostic security | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 36 · page 36 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00443 | 8.4.4.3 Parameter routineResultProof SUV2_REQ 171 The server shall hash the receipt number with the routineStatus routineResult parameter, in this respective order.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 8.4.4.3 Parameter routineResultProof SUV2_REQ 171 The server shall hash the receipt number with the routineStatus routineResult parameter, in this respective order. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 37 · page 37 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00444 | SUV2_REQ 172 The hash algorithm shall be SHA512.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 172 The hash algorithm shall be SHA512. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 37 · page 37 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00445 | SUV2_REQ 173 The server shall sign the hashed output using the receipt-keys.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | High Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 173 The server shall sign the hashed output using the receipt-keys. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 37 · page 37 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00446 | SUV2_REQ 174 The server shall use ED25519 as signature algorithm.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-DAI-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 174 The server shall use ED25519 as signature algorithm. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-DAI-004 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 37 · page 37 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00447 | SUV2_REQ 175 The server shall return in the parameter routineResultProof the signed hash.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 175 The server shall return in the parameter routineResultProof the signed hash. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 37 · page 37 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00448 | Page 38 Figure 5: diagram for signing of software update results 8.4.4.4 Client behaviour after server software verification SUV2_REQ 183 The client shall send the Servers routineStatus routineResult response to the backend.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior; Secure software update and flash readiness; Security evidence and traceability / OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface SSR: SSR-UPD-003 | High Proposal Ready Open point: OP-004 | DetailsFull requirement text Page 38 Figure 5: diagram for signing of software update results 8.4.4.4 Client behaviour after server software verification SUV2_REQ 183 The client shall send the Servers routineStatus routineResult response to the backend. Engineering expectation Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-004 Traceability Feature: Application software behavior; Secure software update and flash readiness; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Application Software; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-UPD-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 38 · page 38 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling High, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00449 | SUV2_REQ 176 Once a SDSC has being accepted by the server, the server shall store in the NVM the receipt number sent over as part of the EMP request.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 176 Once a SDSC has being accepted by the server, the server shall store in the NVM the receipt number sent over as part of the EMP request. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 38 · page 38 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00450 | Once a SDSC has being accepted by the server, the server shall accept the following diagnostic services and routines: SUV2_REQ 177 • Routine 0xFF00 Erase Memory SUV2_REQ 178 • Service 0x34 RequestDownload SUV2_REQ 179 • Service 0x36 TransferData SUV2_REQ 180 • Service 0x37 RequestTransferExitExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Diagnostic security | Feature / interface: Diagnostic security Architecture: Security Services SSR: SSR-RBAC-001 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text Once a SDSC has being accepted by the server, the server shall accept the following diagnostic services and routines: SUV2_REQ 177 • Routine 0xFF00 Erase Memory SUV2_REQ 178 • Service 0x34 RequestDownload SUV2_REQ 179 • Service 0x36 TransferData SUV2_REQ 180 • Service 0x37 RequestTransferExit Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Diagnostic security | Security capability: Diagnostic security | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 38 · page 38 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00451 | Page 39 8.5.1 Request SUV2_REQ 129 The server shall support the routine request according to Table 26.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text Page 39 8.5.1 Request SUV2_REQ 129 The server shall support the routine request according to Table 26. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 39 · page 39 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00452 | Table 26: Routine 0xCAFE Request Format Byte Description Cvt Hex #1 RoutineControl Request SID M 0x31 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) M 0xCA #4 routineIdentifier (LSB) M 0xFE #5 … #n EMP Message M 0x00 – 0xFF 8.5.2 Positive Response SUV2_REQ 130 The server shall support the routine positive response according to Table 27.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text Table 26: Routine 0xCAFE Request Format Byte Description Cvt Hex #1 RoutineControl Request SID M 0x31 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) M 0xCA #4 routineIdentifier (LSB) M 0xFE #5 … #n EMP Message M 0x00 – 0xFF 8.5.2 Positive Response SUV2_REQ 130 The server shall support the routine positive response according to Table 27. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 39 · page 39 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00453 | #n EMP Message M 0x00-0xFF 8.5.3 Negative Response SUV2_REQ 131 SUV2_REQ 132 The server shall support the routine negative response according to CVS33.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text #n EMP Message M 0x00-0xFF 8.5.3 Negative Response SUV2_REQ 131 SUV2_REQ 132 The server shall support the routine negative response according to CVS33. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 39 · page 39 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00454 | 8.5.4 Routine 0xCAFE Parameters 8.5.4.1 Parameter EMP Message SUV2_REQ 133 The server shall support the parameter EMP message according to CVS33.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text 8.5.4 Routine 0xCAFE Parameters 8.5.4.1 Parameter EMP Message SUV2_REQ 133 The server shall support the parameter EMP message according to CVS33. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 39 · page 39 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00455 | Page 40 9 Software Verification and Encryption Requirements SUV2_INFO 117 The information required for the server for verifying software integrity and optionally decrypt the transported data from a trusted source, is described in a Software Data Security Container (SDSC).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Secure communication | Feature / interface: Secure communication; Security evidence and traceability / OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface SSR: SSR-COM-007 | High Proposal Ready Open point: - | DetailsFull requirement text Page 40 9 Software Verification and Encryption Requirements SUV2_INFO 117 The information required for the server for verifying software integrity and optionally decrypt the transported data from a trusted source, is described in a Software Data Security Container (SDSC). Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Secure communication; Security evidence and traceability | Security capability: Secure communication | Interface: OEM/Customer Review Interface | Architecture: Security Services; OEM/Customer Review Interface | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-COM-007 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 40 · page 40 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00456 | 9.1 General Requirements on SDSC 9.1.1 SDSC Structure SUV2_REQ 134 The server shall implement SDSC structure as defined in CVS154.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text 9.1 General Requirements on SDSC 9.1.1 SDSC Structure SUV2_REQ 134 The server shall implement SDSC structure as defined in CVS154. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 40 · page 40 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00457 | SUV2_REQ 184 The range start field shall be the memory address offset from the dataLocator field.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Hardware platform support Architecture: Hardware Platform SSR: SSR-HW-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 184 The range start field shall be the memory address offset from the dataLocator field. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-HW-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 40 · page 40 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00458 | SUV2_REQ 185 The range length field shall be the number of bytes to be verified.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 185 The range length field shall be the number of bytes to be verified. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 40 · page 40 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00459 | SUV2_REQ 161 The supplier shall propose for each software module an identification to be used in dataLocator field in SDSC.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior / OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface SSR: SSR-SYS-008 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 161 The supplier shall propose for each software module an identification to be used in dataLocator field in SDSC. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Application Software; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-008 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 40 · page 40 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00460 | SUV2_REQ 168 The vehicle manufacturer shall review and accept the proposals for every dataLocator.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: Compliance Process; OEM/Customer Review Interface SSR: SSR-SYS-009 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 168 The vehicle manufacturer shall review and accept the proposals for every dataLocator. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Compliance Process; OEM/Customer Review Interface | Work product: DIA / cybersecurity case | SSR: SSR-SYS-009 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 40 · page 40 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00461 | The start address shall be used as an offset in the software module while the length can be utilized to know which areas of the software module are to be verified and/or decrypted.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-008 | Medium Proposal Ready Open point: - | DetailsFull requirement text The start address shall be used as an offset in the software module while the length can be utilized to know which areas of the software module are to be verified and/or decrypted. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-008 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 40 · page 40 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00462 | 9.1.2 SDSC Sanity Check SUV2_REQ 135 Before accepting the SDSC as valid, the server shall perform the sanity check of the received SDSC as defined in CVS154.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text 9.1.2 SDSC Sanity Check SUV2_REQ 135 Before accepting the SDSC as valid, the server shall perform the sanity check of the received SDSC as defined in CVS154. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 40 · page 40 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00463 | SUV2_REQ 138 If the sanity check returns fail/invalid, the server shall reject SDSC as described in CVS34.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 138 If the sanity check returns fail/invalid, the server shall reject SDSC as described in CVS34. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 41 · page 41 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00464 | 9.2 Software Verification SUV2_REQ 152 The server shall validate each VerificationEntry found in the SDSC.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior; Security evidence and traceability / OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface SSR: SSR-VV-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text 9.2 Software Verification SUV2_REQ 152 The server shall validate each VerificationEntry found in the SDSC. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Application Software; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-VV-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 41 · page 41 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00465 | SUV2_REQ 153 Software hashes in the SDSC shall be verified by the server considering the ranges which are stated in the SDSC.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-008 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 153 Software hashes in the SDSC shall be verified by the server considering the ranges which are stated in the SDSC. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-008 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 41 · page 41 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00466 | SUV2_REQ 154 The Ranges dictates the data range that the server shall begin, and end read from NVM for hashing.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 154 The Ranges dictates the data range that the server shall begin, and end read from NVM for hashing. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 41 · page 41 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00467 | SUV2_INFO 126 The Ranges can be one or several if there are gaps between memory areas which shall be excluded from the hash calculation for some reason.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Hardware platform support Architecture: Hardware Platform SSR: SSR-COM-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_INFO 126 The Ranges can be one or several if there are gaps between memory areas which shall be excluded from the hash calculation for some reason. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-COM-005 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 41 · page 41 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00468 | SUV2_REQ 155 When hashing software, the whole memory range, including erased-only bytes of a memory module, shall be possible to include in the hash calculation.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-008 | Low Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 155 When hashing software, the whole memory range, including erased-only bytes of a memory module, shall be possible to include in the hash calculation. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-008 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 41 · page 41 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00469 | Figure 6: Erased-only bytes of a memory module SUV2_REQ 156 The byte value of an erased data byte (typically FF or 00) depends on the MCU/Flash memory and shall be specified by the software supplier as an input for the hashing process.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior; Secure software update and flash readiness / OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface SSR: SSR-UPD-003 | High Proposal Ready Open point: - | DetailsFull requirement text Figure 6: Erased-only bytes of a memory module SUV2_REQ 156 The byte value of an erased data byte (typically FF or 00) depends on the MCU/Flash memory and shall be specified by the software supplier as an input for the hashing process. Engineering expectation Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Secure software update and flash readiness | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Application Software; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-UPD-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 41 · page 41 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00470 | Page 42 SUV2_REQ 157 The server shall be able to verify that erased-only blocks covered in range of memory are erased.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Hardware platform support Architecture: Hardware Platform SSR: SSR-HW-001 | Low Proposal Ready Open point: - | DetailsFull requirement text Page 42 SUV2_REQ 157 The server shall be able to verify that erased-only blocks covered in range of memory are erased. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-HW-001 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 42 · page 42 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT High, HW/Test High Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00471 | SUV2_REQ 158 When the server has verified all verificationEntries, a result OK/NOT_OK shall be returned.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration; Security evidence and traceability / OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface SSR: SSR-VV-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 158 When the server has verified all verificationEntries, a result OK/NOT_OK shall be returned. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Backend and IT Systems; OEM/Customer Review Interface | Work product: Requirement traceability record | SSR: SSR-VV-002 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 42 · page 42 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00472 | SUV2_REQ 159 If NOT_OK is returned, the server shall not accept the new software for execution.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-008 | Low Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 159 If NOT_OK is returned, the server shall not accept the new software for execution. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-008 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 42 · page 42 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00473 | SUV2_REQ 160 If OK is returned, the server shall accept that installed software is valid in terms of integrity.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DAI-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 160 If OK is returned, the server shall accept that installed software is valid in terms of integrity. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DAI-003 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 42 · page 42 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00474 | SUV2_INFO 131 The server may execute other checks to verify the software before concluding if the installed software shall be accepted.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-008 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_INFO 131 The server may execute other checks to verify the software before concluding if the installed software shall be accepted. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-008 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 42 · page 42 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00475 | 9.3 Software decryption SUV2_REQ 147 For the received data, where a match is found in the EncryptionEntry of the DSC, the server shall initialize a cipher if not previously initialized.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-008 | Medium Proposal Ready Open point: - | DetailsFull requirement text 9.3 Software decryption SUV2_REQ 147 For the received data, where a match is found in the EncryptionEntry of the DSC, the server shall initialize a cipher if not previously initialized. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-008 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 42 · page 42 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00476 | SUV2_REQ 148 An initialized data (i.e., cipher scheme) shall be kept active until no more received data matches the current EncryptionEntry.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 148 An initialized data (i.e., cipher scheme) shall be kept active until no more received data matches the current EncryptionEntry. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-004 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 42 · page 42 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00477 | SUV2_REQ 149 The cipher shall be reinitialized for each new Encryption entry.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 149 The cipher shall be reinitialized for each new Encryption entry. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 42 · page 42 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00478 | SUV2_REQ 150 According to best practise received data shall be decrypted “on the fly” before storing to NVM.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text SUV2_REQ 150 According to best practise received data shall be decrypted “on the fly” before storing to NVM. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 42 · page 42 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00479 | Other methods shall be agreed upon with OEM.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text Other methods shall be agreed upon with OEM. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 42 · page 42 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00480 | SUV2_INFO 134 The received data to decrypt may only be parts of a software module and it will be based on the range defined.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: None | Low Proposal Ready Open point: - | DetailsFull requirement text SUV2_INFO 134 The received data to decrypt may only be parts of a software module and it will be based on the range defined. Engineering expectation Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Constraint (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 42 · page 42 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00481 | Note that more than one Address field can be specified if there are one or more areas within a memory module which must be excluded in the hash due to some logical restrictions (e.g., boot writing internal data to such area during programming).Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Hardware platform support; Secure software update and flash readiness Architecture: Hardware Platform SSR: SSR-UPD-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text Note that more than one Address field can be specified if there are one or more areas within a memory module which must be excluded in the hash due to some logical restrictions (e.g., boot writing internal data to such area during programming). Engineering expectation Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-UPD-002 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 48 · page 48 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00482 | S-record Memory layout #00868000 #008AFFFF #00930000 #00BFFFFF #008B0000 #0092FFFF Module hashData #00AFAAAA #00AFAAAB When ECU recieves data that matches an address range in an EncryptionEntry (here in Module B), the server must decrypt the data received by TransferData request.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Hardware platform support Architecture: Hardware Platform SSR: SSR-SDT-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text S-record Memory layout #00868000 #008AFFFF #00930000 #00BFFFFF #008B0000 #0092FFFF Module hashData #00AFAAAA #00AFAAAB When ECU recieves data that matches an address range in an EncryptionEntry (here in Module B), the server must decrypt the data received by TransferData request. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-SDT-002 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 50 · page 50 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test High Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00483 | Module B is encrypted meaning that when the server receives data within a range (given as address and size in RequestDownload) the server must decrypt the data before storing it.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text Module B is encrypted meaning that when the server receives data within a range (given as address and size in RequestDownload) the server must decrypt the data before storing it. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS123-2.md · CVS123-2 > Page 50 · page 50 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00484 | The User shall apply the latest version of this CVS124.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text The User shall apply the latest version of this CVS124. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 1 · page 1 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00485 | Internal Page 2 (90) Foreword This CVS124 contains requirement specification for TRATON GROUP and may be used by all within TRATON Group, if applicable.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | Low Proposal Ready Open point: - | DetailsFull requirement text Internal Page 2 (90) Foreword This CVS124 contains requirement specification for TRATON GROUP and may be used by all within TRATON Group, if applicable. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 2 · page 2 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00486 | Any review of CVS124 shall only be done in agreement with the involved departments stated in the table on the first page under section “Technical responsibility”.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-SYS-009 | Low Proposal Ready Open point: - | DetailsFull requirement text Any review of CVS124 shall only be done in agreement with the involved departments stated in the table on the first page under section “Technical responsibility”. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-SYS-009 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 2 · page 2 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00487 | • Affiliate means any legal entity that directly or indirectly controls, is controlled by, or is commonly controlled with TRATON SE, it is being understood that “control” shall mean ownership of at least 50% of the voting rights or interest in the issued share capital, including for the avoidance of doubt any branch.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | Low Proposal Ready Open point: - | DetailsFull requirement text • Affiliate means any legal entity that directly or indirectly controls, is controlled by, or is commonly controlled with TRATON SE, it is being understood that “control” shall mean ownership of at least 50% of the voting rights or interest in the issued share capital, including for the avoidance of doubt any branch. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 2 · page 2 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00488 | 4 Terms, definitions and abbreviations 4.1 Terms Table 1 – Definition of Terms Term Definition Shall This word, or the terms "Required" or "Must", means that the definition is an absolute requirement of the specification.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Needs Customer Clarification | Needs customer clarification. The requirement implies customer-owned infrastructure, approval, or a responsibility split that is not yet available.Decision: Send linked open point to the customer for decision. | None | Feature / interface: System behavior Architecture: System Core SSR: None | Unknown Reviewed Internally Open point: OP-011 | DetailsFull requirement text 4 Terms, definitions and abbreviations 4.1 Terms Table 1 – Definition of Terms Term Definition Shall This word, or the terms "Required" or "Must", means that the definition is an absolute requirement of the specification. Engineering expectation Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Supplier proposal Needs customer clarification. The requirement implies customer-owned infrastructure, approval, or a responsibility split that is not yet available. Rationale Flagged customer_clarification_needed=yes during extraction. Implementation approach Hold implementation; raise an open point and a clarification question. Acceptance condition Customer answers the linked open point. Customer feedback - Customer decision - Customer clarification / open point Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline. Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort Unknown, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Scope and effort cannot be frozen; estimation carries an open assumption and downstream design may rework. Next action Send linked open point to the customer for decision. |
| REQ-AUTO-00489 | Shall not This phrase, or the phrase "Must not", means that the definition is an absolute prohibition of the specification.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Low Proposal Ready Open point: - | DetailsFull requirement text Shall not This phrase, or the phrase "Must not", means that the definition is an absolute prohibition of the specification. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00490 | Should This word, or the adjective “Recommended”, means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications shall be understood and carefully weighed before choosing a different course.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text Should This word, or the adjective “Recommended”, means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications shall be understood and carefully weighed before choosing a different course. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00491 | Should not This phrase, or the phrase “Not recommended”, means that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Needs Internal Review | Needs internal review. Confirm whether this should-level requirement is in the committed baseline.Decision: Complete internal review of wording and baseline scope. | None | Feature / interface: System behavior Architecture: System Core SSR: None | Low Reviewed Internally Open point: - | DetailsFull requirement text Should not This phrase, or the phrase “Not recommended”, means that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Needs internal review. Confirm whether this should-level requirement is in the committed baseline. Rationale Non-mandatory wording; baseline inclusion not yet confirmed. Implementation approach Decide baseline inclusion internally, then issue an Accept/Partial position. Acceptance condition Internal baseline decision recorded. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Complete internal review of wording and baseline scope. |
| REQ-AUTO-00492 | May This word, or the adjective “Optional”, means that an item is truly optional.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | Low Proposal Ready Open point: - | DetailsFull requirement text May This word, or the adjective “Optional”, means that an item is truly optional. Engineering expectation Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00493 | One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00494 | An implementation which does not include a particular option shall be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text An implementation which does not include a particular option shall be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00495 | In the same vein an implementation which does include a particular option shall be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text In the same vein an implementation which does include a particular option shall be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides). Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00496 | Internal Page 7 (90) ISO International Organization for Standardization non-Def Non-default diagnostic session ODX Open Diagnostic Data Exchange, ODX-Standard (ASAM MCD-2D) Prg Programming diagnostic session SPN Suspected Parameter Number PDU Protocol Data Unit SID Service Identification Data IVD Integrity Validation Data RBAC Role Base Access Control RBACC RBAC Configuration SPRMIB Suppress Positive Response Message Indication Bit A_ASCIISTRING ODX BASE-DATA-TYPE for an ASCII coded character field (ISO 8859-1) min-max-length zero The bit length of the ODX element DOP (DATA-OBJECT-PROP) is variable; minimal and maximal length is given in bytes; the termination is ZERO for binary and ‘NULL’ for ASCII 4.3 Conventions Table 3 – Conventions Implementation Description M Mandatory Mandatory data marked as ‘M’ always shall be returned.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | Diagnostic security | Feature / interface: Diagnostic security; Secure software update and flash readiness; Security evidence and traceability / OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface SSR: SSR-RBAC-001 | High Proposal Ready Open point: - | DetailsFull requirement text Internal Page 7 (90) ISO International Organization for Standardization non-Def Non-default diagnostic session ODX Open Diagnostic Data Exchange, ODX-Standard (ASAM MCD-2D) Prg Programming diagnostic session SPN Suspected Parameter Number PDU Protocol Data Unit SID Service Identification Data IVD Integrity Validation Data RBAC Role Base Access Control RBACC RBAC Configuration SPRMIB Suppress Positive Response Message Indication Bit A_ASCIISTRING ODX BASE-DATA-TYPE for an ASCII coded character field (ISO 8859-1) min-max-length zero The bit length of the ODX element DOP (DATA-OBJECT-PROP) is variable; minimal and maximal length is given in bytes; the termination is ZERO for binary and ‘NULL’ for ASCII 4.3 Conventions Table 3 – Conventions Implementation Description M Mandatory Mandatory data marked as ‘M’ always shall be returned. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Diagnostic security; Secure software update and flash readiness; Security evidence and traceability | Security capability: Diagnostic security | Interface: OEM/Customer Review Interface | Architecture: Security Services; OEM/Customer Review Interface | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 7 · page 7 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00497 | If valid data is not needed for the use-case and system at hand, default values should be used.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Needs Internal Review | Needs internal review. Confirm whether this should-level requirement is in the committed baseline.Decision: Complete internal review of wording and baseline scope. | None | Feature / interface: System behavior Architecture: System Core SSR: None | Low Reviewed Internally Open point: - | DetailsFull requirement text If valid data is not needed for the use-case and system at hand, default values should be used. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Needs internal review. Confirm whether this should-level requirement is in the committed baseline. Rationale Non-mandatory wording; baseline inclusion not yet confirmed. Implementation approach Decide baseline inclusion internally, then issue an Accept/Partial position. Acceptance condition Internal baseline decision recorded. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 7 · page 7 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Complete internal review of wording and baseline scope. |
| REQ-AUTO-00498 | E Mandatory for ECUs which shall be compliant with OBD legislation Worldwide like ISO27145,J1979 etc C Conditional U User optional.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text E Mandatory for ECUs which shall be compliant with OBD legislation Worldwide like ISO27145,J1979 etc C Conditional U User optional. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 7 · page 7 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00499 | Shall be agreed between the supplier and the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text Shall be agreed between the supplier and the vehicle manufacturer. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 7 · page 7 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0001 | Internal Page 8 (90) 5 Requirements 5.1 General RequirementsThe implementation of the client and the server shall be compliant with ISO 14229-1 with the clarifications, extensions and exceptions stated in this specification.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-DIAG-003 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text Internal Page 8 (90) 5 Requirements 5.1 General Requirements REQ_UDS 0001 The implementation of the client and the server shall be compliant with ISO 14229-1 with the clarifications, extensions and exceptions stated in this specification. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-DIAG-003 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0002 | All deviations and extensions shall be agreed with the applicable vehicle manufacturer and shall be documented.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-DIAG-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0002 All deviations and extensions shall be agreed with the applicable vehicle manufacturer and shall be documented. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0003 | Modified requirementsAdded semantic Identifier DIDs, changed the NodeUID DID to INTERNAL REQ_UDS 0034: Change in the length of NodeUID(0xF1AF) INFO_UDS 0040: Change in the retrieval method for NodeUID(0xF1AF) REQ_UDS 0036: 0xF1B9 RBACCIdentifierNumber is changed to Mandatory REQ_UDS 0037: 0xF1BA RBACCStructureVersion,bit-length changed REQ_UDS 0045: Changes for service (0x84) and (0x31) REQ_UDS 0048: Updated the document references REQ_UDS 0107: 0XCAFE and 0xFF02 are updated to Mandatory REQ_UDS 0180: Modifcations on the bit values and new bit added REQ_UDS 0193: 0x05 is changed to Mandatory 6 Normative references: Updated the referenced documents and versions Removed Requirements and infos: REQ_UDS 0045: (0x86) service removed REQ_UDS 0053, REQ_UDS 0054: Removed the reserved DID ranges and 0xF1C1 REQ_UDS 0024: 0xF19E ODXFileDataIdentifier is removed 2024-10 First issueExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: Secure communication and freshness protection Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text Modified requirements: REQ_UDS 0003: Added semantic Identifier DIDs, changed the NodeUID DID to INTERNAL REQ_UDS 0034: Change in the length of NodeUID(0xF1AF) INFO_UDS 0040: Change in the retrieval method for NodeUID(0xF1AF) REQ_UDS 0036: 0xF1B9 RBACCIdentifierNumber is changed to Mandatory REQ_UDS 0037: 0xF1BA RBACCStructureVersion,bit-length changed REQ_UDS 0045: Changes for service (0x84) and (0x31) REQ_UDS 0048: Updated the document references REQ_UDS 0107: 0XCAFE and 0xFF02 are updated to Mandatory REQ_UDS 0180: Modifcations on the bit values and new bit added REQ_UDS 0193: 0x05 is changed to Mandatory 6 Normative references: Updated the referenced documents and versions Removed Requirements and infos: REQ_UDS 0045: (0x86) service removed REQ_UDS 0053, REQ_UDS 0054: Removed the reserved DID ranges and 0xF1C1 REQ_UDS 0024: 0xF19E ODXFileDataIdentifier is removed 2024-10 First issue Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Secure communication and freshness protection | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Medium, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0004 | Internal Page 10 (90) 5.2.1.1 DID 0xF180 bootSoftwareIdentificationDataIdentifierTable 6 – Description of DID 0xF180 bootSoftwareIdentificationDataIdentifier 0xF180 Name : bootSoftwareIdentificationDataIdentifier Byte Data #1 numberOfModules 1-Byte-A_UINT32 M 0x01 0x01 #2 : #14 Boot software identifier #1: : M : M 0x7E .Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text Internal Page 10 (90) 5.2.1.1 DID 0xF180 bootSoftwareIdentificationDataIdentifier REQ_UDS 0004 Table 6 – Description of DID 0xF180 bootSoftwareIdentificationDataIdentifier 0xF180 Name : bootSoftwareIdentificationDataIdentifier Byte Data #1 numberOfModules 1-Byte-A_UINT32 M 0x01 0x01 #2 : #14 Boot software identifier #1: : M : M 0x7E . Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0005 | 0x20This DID shall be stored under flash memory module in flash memory.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Hardware platform support; Secure software update and flash readiness Architecture: Hardware Platform SSR: SSR-UPD-002 | High Proposal Ready Open point: - | DetailsFull requirement text 0x20 REQ_UDS 0005 This DID shall be stored under flash memory module in flash memory. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-UPD-002 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Medium, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0006 | 5.2.1.2 DID 0xF181 applicationSoftwareIdentificationDataIdentifierTable 7 – Description of DID 0xF181 applicationSoftwareIdentificationDataIdentifier 0xF181 Name : applicationSoftwareIdentificationDataIdentifier Byte Data #1 numberOfModules 1-Byte-A_UINT32 M 0x01 0x02 – 0xFF 0x01 #2 : #14 Application software identifier #1: : M 0x7E 0x7E 0x20 : : : #n – 12 : #n Application software identifier #m: : C 0x7E 0x7E 0x20Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.2.1.2 DID 0xF181 applicationSoftwareIdentificationDataIdentifier REQ_UDS 0006 Table 7 – Description of DID 0xF181 applicationSoftwareIdentificationDataIdentifier 0xF181 Name : applicationSoftwareIdentificationDataIdentifier Byte Data #1 numberOfModules 1-Byte-A_UINT32 M 0x01 0x02 – 0xFF 0x01 #2 : #14 Application software identifier #1: : M 0x7E 0x7E 0x20 : : : #n – 12 : #n Application software identifier #m: : C 0x7E 0x7E 0x20 Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0007 | Internal Page 11 (90) REQ_UDS 0231 5.2.1.3 DID 0xF182 applicationDataIdentificationDataIdentifierTable 8 – Description of DID 0xF182 applicationDataIdentificationDataIdentifier 0xF182 Name: applicationDataIdentificationDataIdentifier Byte No Description Format Cvt Byte Value Default Data #1 numberOfModules 1-Byte-A_UINT32 M 0x01 0x02 – 0xFF 0x01 #2 : #14 Application data module part number #1: : 13 Bytes- M : M 0x7E .Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text Internal Page 11 (90) REQ_UDS 0231 5.2.1.3 DID 0xF182 applicationDataIdentificationDataIdentifier REQ_UDS 0007 Table 8 – Description of DID 0xF182 applicationDataIdentificationDataIdentifier 0xF182 Name: applicationDataIdentificationDataIdentifier Byte No Description Format Cvt Byte Value Default Data #1 numberOfModules 1-Byte-A_UINT32 M 0x01 0x02 – 0xFF 0x01 #2 : #14 Application data module part number #1: : 13 Bytes- M : M 0x7E . Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0232 | 0x7E 0x20This DID shall be stored under dataset module stored in flash memory.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Hardware platform support; Secure software update and flash readiness Architecture: Hardware Platform SSR: SSR-UPD-002 | High Proposal Ready Open point: - | DetailsFull requirement text 0x7E 0x20 REQ_UDS 0232 This DID shall be stored under dataset module stored in flash memory. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-UPD-002 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Medium, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0008 | 5.2.1.4 DID 0xF186 ActiveDiagnosticSessionDataIdentifierTable 9 – Description of DID 0xF186 ActiveDiagnosticSessionDataIdentifier 0xF186 Name: ActiveDiagnosticSessionDataIdentifier Byte No Description Format Cvt Byte Value Default Data #1 Diagnostic session type 1-Byte-A_UINT32 M 0x00 – 0xFF 0x01Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | High Proposal Ready Open point: - | DetailsFull requirement text 5.2.1.4 DID 0xF186 ActiveDiagnosticSessionDataIdentifier REQ_UDS 0008 Table 9 – Description of DID 0xF186 ActiveDiagnosticSessionDataIdentifier 0xF186 Name: ActiveDiagnosticSessionDataIdentifier Byte No Description Format Cvt Byte Value Default Data #1 Diagnostic session type 1-Byte-A_UINT32 M 0x00 – 0xFF 0x01 Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Cybersecurity control (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0009 | Internal Page 12 (90) 5.2.1.5 DID 0xF187 vehicleManufacturerSparePartNumberDataIdentifierTable 10 – Description of DID 0xF187 vehicleManufacturerSparePartNumberDataIdentifier 0xF187 Name: vehicleManufacturerSparePartNumberDataIdentifier Byte No Description Format Cvt Byte Value Default Data #1 : #13 Vehicle manufacturer sparepart number : G, M : M 0x7E : 0x7E 0x20 REQ_UDS 0233 This DID shall be stored under dataset module stored in flash memory.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Hardware platform support; Secure software update and flash readiness / OEM/Customer Review Interface Architecture: Hardware Platform; OEM/Customer Review Interface SSR: SSR-UPD-002 | High Proposal Ready Open point: - | DetailsFull requirement text Internal Page 12 (90) 5.2.1.5 DID 0xF187 vehicleManufacturerSparePartNumberDataIdentifier REQ_UDS 0009 Table 10 – Description of DID 0xF187 vehicleManufacturerSparePartNumberDataIdentifier 0xF187 Name: vehicleManufacturerSparePartNumberDataIdentifier Byte No Description Format Cvt Byte Value Default Data #1 : #13 Vehicle manufacturer sparepart number : G, M : M 0x7E : 0x7E 0x20 REQ_UDS 0233 This DID shall be stored under dataset module stored in flash memory. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support; Secure software update and flash readiness | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Hardware Platform; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-UPD-002 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Medium, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0010 | 5.2.1.6 DID 0xF188 vehicleManufacturerECUSoftwareNumberDataIdentifierTable 11 – Description of DID 0xF188 vehicleManufacturerECUSoftwareNumberDataIdentifier 0xF188 Name: vehicleManufacturerECUSoftwareNumberDataIdentifier Byte Data #1 : #13 Vehicle manufacturer ECU (server) software number : M : M : 0x20 REQ_UDS 0234 5.2.1.7 DID 0xF189 vehicleManufacturerECUSoftwareVersionNumberDataIdentifier REQ_UDS 0011 Table 12 – Description of DID 0xF189 vehicleManufacturerECUSoftwareVersionNumberDataIdentifier 0xF189 Name: vehicleManufacturerECUSoftwareVersionNumberDataIdentifier Byte DataExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.2.1.6 DID 0xF188 vehicleManufacturerECUSoftwareNumberDataIdentifier REQ_UDS 0010 Table 11 – Description of DID 0xF188 vehicleManufacturerECUSoftwareNumberDataIdentifier 0xF188 Name: vehicleManufacturerECUSoftwareNumberDataIdentifier Byte Data #1 : #13 Vehicle manufacturer ECU (server) software number : M : M : 0x20 REQ_UDS 0234 5.2.1.7 DID 0xF189 vehicleManufacturerECUSoftwareVersionNumberDataIdentifier REQ_UDS 0011 Table 12 – Description of DID 0xF189 vehicleManufacturerECUSoftwareVersionNumberDataIdentifier 0xF189 Name: vehicleManufacturerECUSoftwareVersionNumberDataIdentifier Byte Data Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT High, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0012 | Byte #7 Correction Byte #8 Correction Byte #9 Correction Byte #10 Correction XX.YY.ZZZZ (XX – Major version YY-Minor version ZZZZ – Extra release within XX.YY for Bug fixes, Functional updates etc) 10Bytes- A_ASCIISTR ING, min-max- length zero M : M : 0x20 REQ_UDS 0235 5.2.1.8 DID 0xF18A systemSupplierIdentifierDataIdentifier Table 13 – Description of DID 0xF18A systemSupplierIdentifierDataIdentifier 0xF18A Name: systemSupplierIdentifierDataIdentifier Byte No Description Format Cvt Byte Value Default Data To be specifie d by the Content and format to be specified by the supplier Should be M : M : 5.2.1.9 DID 0xF18B ECUManufacturingDateDataIdentifier REQ_UDS 0013 Table 14 – Description of DID 0xF18B ECUManufacturingDateDataIdentifier 0xF18B Name: ECUManufacturingDateDataIdentifier Byte Data #1 .Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-DIAG-001 | High Proposal Ready Open point: - | DetailsFull requirement text Byte #7 Correction Byte #8 Correction Byte #9 Correction Byte #10 Correction XX.YY.ZZZZ (XX – Major version YY-Minor version ZZZZ – Extra release within XX.YY for Bug fixes, Functional updates etc) 10Bytes- A_ASCIISTR ING, min-max- length zero M : M : 0x20 REQ_UDS 0235 5.2.1.8 DID 0xF18A systemSupplierIdentifierDataIdentifier REQ_UDS 0012 Table 13 – Description of DID 0xF18A systemSupplierIdentifierDataIdentifier 0xF18A Name: systemSupplierIdentifierDataIdentifier Byte No Description Format Cvt Byte Value Default Data To be specifie d by the Content and format to be specified by the supplier Should be M : M : 5.2.1.9 DID 0xF18B ECUManufacturingDateDataIdentifier REQ_UDS 0013 Table 14 – Description of DID 0xF18B ECUManufacturingDateDataIdentifier 0xF18B Name: ECUManufacturingDateDataIdentifier Byte Data #1 . Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 13 · page 13 Estimation / resource / tool / IT / hardware impact Effort High, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0014 | Internal Page 14 (90) byte #3 YY byte #4 YY byte #5 MM byte #6 MM byte #7 DD byte #8 DD 0x20, 0x30 – 0x39 5.2.1.10 DID 0xF18C ECUSerialNumberDataIdentifier Table 15 – Description of DID 0xF18C ECUSerialNumberDataIdentifier 0xF18C Name: ECUSerialNumberDataIdentifier Byte Data To be specified by the supplier.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text Internal Page 14 (90) byte #3 YY byte #4 YY byte #5 MM byte #6 MM byte #7 DD byte #8 DD 0x20, 0x30 – 0x39 5.2.1.10 DID 0xF18C ECUSerialNumberDataIdentifier REQ_UDS 0014 Table 15 – Description of DID 0xF18C ECUSerialNumberDataIdentifier 0xF18C Name: ECUSerialNumberDataIdentifier Byte Data To be specified by the supplier. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 14 · page 14 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00513 | Minimum length shall be 8 bytes and the assigned value shall be unique for every unit provided by one supplier per project.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text Minimum length shall be 8 bytes and the assigned value shall be unique for every unit provided by one supplier per project. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 14 · page 14 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0015 | 5.2.1.11 DID 0xF190 VINDataIdentifierTable 16 – Description of DID 0xF190 VINDataIdentifier 0xF190 Name: VINDataIdentifier Byte Data #1 : #17 VIN number : Byte #17 17-Bytes- M : M : 0x30 .Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.2.1.11 DID 0xF190 VINDataIdentifier REQ_UDS 0015 Table 16 – Description of DID 0xF190 VINDataIdentifier 0xF190 Name: VINDataIdentifier Byte Data #1 : #17 VIN number : Byte #17 17-Bytes- M : M : 0x30 . Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 14 · page 14 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0016 | 5.2.1.12 DID 0xF191 vehicleManufacturerECUHardwareNumberDataIdentifierTable 17 – Description of DID 0xF191 vehicleManufacturerECUHardwareNumberDataIdentifier 0xF191 Name: vehicleManufacturerECUHardwareNumberDataIdentifier Byte DataExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.2.1.12 DID 0xF191 vehicleManufacturerECUHardwareNumberDataIdentifier REQ_UDS 0016 Table 17 – Description of DID 0xF191 vehicleManufacturerECUHardwareNumberDataIdentifier 0xF191 Name: vehicleManufacturerECUHardwareNumberDataIdentifier Byte Data Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 14 · page 14 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0236 | 0x20This DID shall be stored under flash memory module in flash memory.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Hardware platform support; Secure software update and flash readiness Architecture: Hardware Platform SSR: SSR-UPD-002 | High Proposal Ready Open point: - | DetailsFull requirement text 0x20 REQ_UDS 0236 This DID shall be stored under flash memory module in flash memory. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-UPD-002 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 15 · page 15 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Medium, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0017 | 5.2.1.13 DID 0xF192 systemSupplierECUHardwareNumberDataIdentifierTable 18 – Description of DID 0xF192 systemSupplierECUHardwareNumberDataIdentifier 0xF192 Name: systemSupplierECUHardwareNumberDataIdentifier Byte Data To be specified by the External Supplier 5.2.1.14 DID 0xF193 systemSupplierECUHardwareVersionNumberDataIdentifier REQ_UDS 0018 Table 19 – Description of DID 0xF193 systemSupplierECUHardwareVersionNumberDataIdentifier 0xF193 Name: systemSupplierECUHardwareVersionNumberDataIdentifier Byte Data To be specified by the External Supplier 5.2.1.15 DID 0xF194 systemSupplierECUSoftwareNumberDataIdentifier REQ_UDS 0019 Table 20 – Description of DID 0xF194 systemSupplierECUSoftwareNumberDataIdentifier 0xF194 Name: systemSupplierECUSoftwareNumberDataIdentifier Byte No Description Format Cvt Byte Value Data To be specified by the External SupplierExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.2.1.13 DID 0xF192 systemSupplierECUHardwareNumberDataIdentifier REQ_UDS 0017 Table 18 – Description of DID 0xF192 systemSupplierECUHardwareNumberDataIdentifier 0xF192 Name: systemSupplierECUHardwareNumberDataIdentifier Byte Data To be specified by the External Supplier 5.2.1.14 DID 0xF193 systemSupplierECUHardwareVersionNumberDataIdentifier REQ_UDS 0018 Table 19 – Description of DID 0xF193 systemSupplierECUHardwareVersionNumberDataIdentifier 0xF193 Name: systemSupplierECUHardwareVersionNumberDataIdentifier Byte Data To be specified by the External Supplier 5.2.1.15 DID 0xF194 systemSupplierECUSoftwareNumberDataIdentifier REQ_UDS 0019 Table 20 – Description of DID 0xF194 systemSupplierECUSoftwareNumberDataIdentifier 0xF194 Name: systemSupplierECUSoftwareNumberDataIdentifier Byte No Description Format Cvt Byte Value Data To be specified by the External Supplier Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 15 · page 15 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0020 | Internal Page 16 (90) 5.2.1.16 DID 0xF195 systemSupplierECUSoftwareVersionNumberDataIdentifierTable 21 – Description of DID 0xF195 systemSupplierECUSoftwareVersionNumberDataIdentifier 0xF195 Name: systemSupplierECUSoftwareVersionNumberDataIdentifier Byte Data To be specified by the External supplier 5.2.1.17 DID 0xF196 exhaustRegulationOrTypeApprovalNumberDataIdentifier REQ_UDS 0021 Table 22 – Description of DID 0xF196 exhaustRegulationOrTypeApprovalNumberDataIdentifier 0xF196 Name: exhaustRegulationOrTypeApprovalNumberDataIdentifier Cvt: E Byte Data #1 : #10 Exhaust regulation or type approval 10-Bytes- M : M : 0000000 000 5.2.1.18 DID 0xF197 systemNameOrEngineTypeDataIdentifier REQ_UDS 0022 Table 23 – Description of DID 0xF197 systemNameOrEngineTypeDataIdentifier 0xF197 Name: systemNameOrEngineTypeDataIdentifier Byte Data #1 : #22 System name or engine type 6-to-22-Bytes- G, M : C : 0x20 .Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text Internal Page 16 (90) 5.2.1.16 DID 0xF195 systemSupplierECUSoftwareVersionNumberDataIdentifier REQ_UDS 0020 Table 21 – Description of DID 0xF195 systemSupplierECUSoftwareVersionNumberDataIdentifier 0xF195 Name: systemSupplierECUSoftwareVersionNumberDataIdentifier Byte Data To be specified by the External supplier 5.2.1.17 DID 0xF196 exhaustRegulationOrTypeApprovalNumberDataIdentifier REQ_UDS 0021 Table 22 – Description of DID 0xF196 exhaustRegulationOrTypeApprovalNumberDataIdentifier 0xF196 Name: exhaustRegulationOrTypeApprovalNumberDataIdentifier Cvt: E Byte Data #1 : #10 Exhaust regulation or type approval 10-Bytes- M : M : 0000000 000 5.2.1.18 DID 0xF197 systemNameOrEngineTypeDataIdentifier REQ_UDS 0022 Table 23 – Description of DID 0xF197 systemNameOrEngineTypeDataIdentifier 0xF197 Name: systemNameOrEngineTypeDataIdentifier Byte Data #1 : #22 System name or engine type 6-to-22-Bytes- G, M : C : 0x20 . Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 16 · page 16 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0237 | 0x20INFO_UDS 0039 The format should follow the pattern: Appl: <Diag.family> <Diag.generation> Boot: <Diag.family> <Diag.generation>_BOOTExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Low Proposal Ready Open point: - | DetailsFull requirement text 0x20 REQ_UDS 0237 INFO_UDS 0039 The format should follow the pattern: Appl: <Diag.family> <Diag.generation> Boot: <Diag.family> <Diag.generation>_BOOT Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 16 · page 16 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0339 | Internal Page 90 (90) Annex C (informative) Change history Release date Changes 2025-12 New requirements and infos: INFO_UDS 0039: F197 structure added F198 Request and response format REQ_UDS 0340: F199 Request and response format REQ_UDS 0341: F19A Request and response format REQ_UDS 0342: NRC for RBACC check failures REQ_UDS 0343, REQ_UDS 0344, REQ_UDS 0345, REQ_UDS 0346, REQ_UDS 0347, REQ_UDS 0348, REQ_UDS 0349: Requirements, Request and response formats for the ControlDTCSetting(0x85) added.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: Secure communication and freshness protection Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text Internal Page 90 (90) Annex C (informative) Change history Release date Changes 2025-12 New requirements and infos: INFO_UDS 0039: F197 structure added REQ_UDS 0339: F198 Request and response format REQ_UDS 0340: F199 Request and response format REQ_UDS 0341: F19A Request and response format REQ_UDS 0342: NRC for RBACC check failures REQ_UDS 0343, REQ_UDS 0344, REQ_UDS 0345, REQ_UDS 0346, REQ_UDS 0347, REQ_UDS 0348, REQ_UDS 0349: Requirements, Request and response formats for the ControlDTCSetting(0x85) added. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Secure communication and freshness protection | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 17 · page 17 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0340 | 5.2.1.20 DID 0xF199 SoftwareAssemblySemanticDataIdentifiersTable 25 – Description of DID 0xF199 SoftwareAssemblySemanticDataIdentifier s 0xF199 Name: SoftwareAssemblySemanticDataIdentifiers Byte Data #1 : #3 numberOfModules(m) 3-Byte- A_UINT32 M 0x000001 – 0xFFFFFF 01Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: Secure communication and freshness protection Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.2.1.20 DID 0xF199 SoftwareAssemblySemanticDataIdentifiers REQ_UDS 0340 Table 25 – Description of DID 0xF199 SoftwareAssemblySemanticDataIdentifier s 0xF199 Name: SoftwareAssemblySemanticDataIdentifiers Byte Data #1 : #3 numberOfModules(m) 3-Byte- A_UINT32 M 0x000001 – 0xFFFFFF 01 Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Secure communication and freshness protection | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 17 · page 17 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0341 | 5.2.1.21 DID 0xF19A HardwareSemanticDataIdentifiersTable 26 – Description of DID 0xF19A HardwareSemanticDataIdentifiers 0xF19A Name: HardwareSemanticDataIdentifiers Byte Data #1 : #3 numberOfModules(m) 3-Byte- A_UINT32 M 0x000001 – 0xFFFFFF 01 #4 : #n+3 HardwareSemantic Data Identifier #1: : byte #n* A_ASCIISTR ING, zero M 0x00, 0x20 – 0x7E : : : : : : : HardwareSemantic Data Identifier #m: : byte #q* A_ASCIISTR ING, zero C 0x00, 0x20 – 0x7E *depends on the SoftwareItemSemanticDataIdentifiers length.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: Secure communication and freshness protection Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.2.1.21 DID 0xF19A HardwareSemanticDataIdentifiers REQ_UDS 0341 Table 26 – Description of DID 0xF19A HardwareSemanticDataIdentifiers 0xF19A Name: HardwareSemanticDataIdentifiers Byte Data #1 : #3 numberOfModules(m) 3-Byte- A_UINT32 M 0x000001 – 0xFFFFFF 01 #4 : #n+3 HardwareSemantic Data Identifier #1: : byte #n* A_ASCIISTR ING, zero M 0x00, 0x20 – 0x7E : : : : : : : HardwareSemantic Data Identifier #m: : byte #q* A_ASCIISTR ING, zero C 0x00, 0x20 – 0x7E *depends on the SoftwareItemSemanticDataIdentifiers length. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Secure communication and freshness protection | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 18 · page 18 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0023 | Internal Page 19 (90) 5.2.1.22 DID 0xF19D ECUInstallationDateDataIdentifierTable 27 – Description of DID 0xF19D ECUInstallationDateDataIdentifier 0xF19D Name: ECUInstallationDateDataIdentifier Byte Data #1 .Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text Internal Page 19 (90) 5.2.1.22 DID 0xF19D ECUInstallationDateDataIdentifier REQ_UDS 0023 Table 27 – Description of DID 0xF19D ECUInstallationDateDataIdentifier 0xF19D Name: ECUInstallationDateDataIdentifier Byte Data #1 . Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 19 · page 19 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0025 | #8 Format: “YYYYMMDD” byte #1 YY (most significant) byte #2 YY byte #3 YY byte #4 YY byte #5 MM byte #6 MM byte #7 DD byte #8 DD 8-Bytes- RING M : M : 0x2020 20202 020 5.2.1.23 DID 0xF1A5 vehicleManufacturerECUHardwareWithoutBootNumber Table 28 – Description of DID 0xF1A5 vehicleMannufacturerECUHardwareWithoutBootNumber 0xF1A5 Name: vehicleManufacturerECUHardwareWithoutBootNumber Byte No: Description Format Cvt Byte Value Default Data #1 : #13 vehicleManufactur er ECU Hardware Number Byte #2 : 13-Byte- M : M : Project 5.2.1.24 DID 0xF1A6 engineNumber REQ_UDS 0026 Table 29 – Description of DID 0xF1A6 engineNumber 0xF1A6 Name: engineNumber Byte Data #1 : #14 Engine number 14-Bytes- A_ASCIISTRING MM : 0x20 C = Applicable only for TRATON standalone engine solutionsExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | Low Proposal Ready Open point: - | DetailsFull requirement text #8 Format: “YYYYMMDD” byte #1 YY (most significant) byte #2 YY byte #3 YY byte #4 YY byte #5 MM byte #6 MM byte #7 DD byte #8 DD 8-Bytes- RING M : M : 0x2020 20202 020 5.2.1.23 DID 0xF1A5 vehicleManufacturerECUHardwareWithoutBootNumber REQ_UDS 0025 Table 28 – Description of DID 0xF1A5 vehicleMannufacturerECUHardwareWithoutBootNumber 0xF1A5 Name: vehicleManufacturerECUHardwareWithoutBootNumber Byte No: Description Format Cvt Byte Value Default Data #1 : #13 vehicleManufactur er ECU Hardware Number Byte #2 : 13-Byte- M : M : Project 5.2.1.24 DID 0xF1A6 engineNumber REQ_UDS 0026 Table 29 – Description of DID 0xF1A6 engineNumber 0xF1A6 Name: engineNumber Byte Data #1 : #14 Engine number 14-Bytes- A_ASCIISTRING MM : 0x20 C = Applicable only for TRATON standalone engine solutions Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Constraint (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 19 · page 19 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT Low, HW/Test High Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0027 | Internal Page 20 (90) 5.2.1.25 DID 0xF1A9 Lifetime ECU-runtime at software update stampThis DID shall contain a snapshot of the mandatory lifetime ECU-runtime operational data variable captured at the first power on after a software update.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior; Secure software update and flash readiness Architecture: Application Software SSR: SSR-UPD-003 | High Proposal Ready Open point: - | DetailsFull requirement text Internal Page 20 (90) 5.2.1.25 DID 0xF1A9 Lifetime ECU-runtime at software update stamp REQ_UDS 0027 This DID shall contain a snapshot of the mandatory lifetime ECU-runtime operational data variable captured at the first power on after a software update. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-UPD-003 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 20 · page 20 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0028 | Table 30 – Description of DID 0xF1A9 Lifetime ECU-runtime at software update stamp 0xF1A9 Name: lifetimeECUruntimeAtSoftwareUpdateStamp Byte No Description Format Cvt Byte Value Default Data #1 : #4 Lifetime ECU- runtime at software update stamp Unit: s A_UINT32 M : M : 0xFFFFFFFF C = mandatory for TRATON Standalone and External engines 5.2.1.26 DID 0xF1AA Mileage at software update stamp REQ_UDS 0029 This DID shall report a snapshot of the mileage of the vehicle as received on CAN or other ECU-external source at the first reception of the signal with a good signal status after a software update.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior; Secure software update and flash readiness Architecture: Application Software SSR: SSR-UPD-003 | High Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0028 Table 30 – Description of DID 0xF1A9 Lifetime ECU-runtime at software update stamp 0xF1A9 Name: lifetimeECUruntimeAtSoftwareUpdateStamp Byte No Description Format Cvt Byte Value Default Data #1 : #4 Lifetime ECU- runtime at software update stamp Unit: s A_UINT32 M : M : 0xFFFFFFFF C = mandatory for TRATON Standalone and External engines 5.2.1.26 DID 0xF1AA Mileage at software update stamp REQ_UDS 0029 This DID shall report a snapshot of the mileage of the vehicle as received on CAN or other ECU-external source at the first reception of the signal with a good signal status after a software update. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-UPD-003 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 20 · page 20 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0030 | Table 31 – Description of DID 0xF1AA Mileage at software update stamp ID Description 0xF1AA Name: mileageAtSoftwareUpdateStamp Byte No Description Format Cvt Byte Value Default Data #1 : #4 Mileage at software update stamp Unit: km Formula: 0,005*X 4-Bytes- A_UINT32 M : M : 0xFFFFFFFF C = Mandatory for ECUs that store Operational data and have access to Vehicle milage information.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: Secure software update and flash readiness Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0030 Table 31 – Description of DID 0xF1AA Mileage at software update stamp ID Description 0xF1AA Name: mileageAtSoftwareUpdateStamp Byte No Description Format Cvt Byte Value Default Data #1 : #4 Mileage at software update stamp Unit: km Formula: 0,005*X 4-Bytes- A_UINT32 M : M : 0xFFFFFFFF C = Mandatory for ECUs that store Operational data and have access to Vehicle milage information. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 20 · page 20 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0032 | Internal Page 21 (90)Table 32 – Description of DID 0xF1AB Date at software update stamp 0xF1AB Name: dateAtSoftwareUpdateStamp Byte Data #1 .Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: Secure software update and flash readiness Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text Internal Page 21 (90) REQ_UDS 0032 Table 32 – Description of DID 0xF1AB Date at software update stamp 0xF1AB Name: dateAtSoftwareUpdateStamp Byte Data #1 . Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 21 · page 21 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0033 | 5.2.1.28 DID 0xF1AD activeECUSoftwareDataIdentifierTable 33 – Description of DID 0xF1AD activeECUSoftwareDataIdentifier 0xF1AD Name: activeECUSoftwareDataIdentifier Byte Data #1 : #2 Active ECU Software 2-Bytes- A_BYTEFIEL D M : M Boot loader: 0x0000 Application Software: 0x0002 No information: 0xFFFF Not applicabl e 5.2.1.29 DID 0xF1AF NodeUID REQ_UDS 0034 Table 34 – Description of DID 0xF1AF NodeUID 0xF1AF Name: NodeUID Byte Data #1 : #8 NodeUID 8-Bytes- A_BYTEFIELD M : M : 0x00 : 0x00Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.2.1.28 DID 0xF1AD activeECUSoftwareDataIdentifier REQ_UDS 0033 Table 33 – Description of DID 0xF1AD activeECUSoftwareDataIdentifier 0xF1AD Name: activeECUSoftwareDataIdentifier Byte Data #1 : #2 Active ECU Software 2-Bytes- A_BYTEFIEL D M : M Boot loader: 0x0000 Application Software: 0x0002 No information: 0xFFFF Not applicabl e 5.2.1.29 DID 0xF1AF NodeUID REQ_UDS 0034 Table 34 – Description of DID 0xF1AF NodeUID 0xF1AF Name: NodeUID Byte Data #1 : #8 NodeUID 8-Bytes- A_BYTEFIELD M : M : 0x00 : 0x00 Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 21 · page 21 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0036 | 5.2.1.30 DID 0xF1B9 RBACCIdentifierNumberTable 35 – Description of DID 0xF1B9 RBACCIdentifierNumber 0xF1B9 Name: RBACCIdentifierNumber Byte Data #1 : #16 RBACC Identifier Number 16-Bytes- A_BYTEFIELD M : M : 0x00 : 0x00 INFO_UDS 0006 Information on RBACC can be found in CVS151.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.2.1.30 DID 0xF1B9 RBACCIdentifierNumber REQ_UDS 0036 Table 35 – Description of DID 0xF1B9 RBACCIdentifierNumber 0xF1B9 Name: RBACCIdentifierNumber Byte Data #1 : #16 RBACC Identifier Number 16-Bytes- A_BYTEFIELD M : M : 0x00 : 0x00 INFO_UDS 0006 Information on RBACC can be found in CVS151. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 22 · page 22 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0037 | 5.2.1.31 DID 0xF1BA RBACCStructureVersionTable 36 – Description of DID 0xF1BA RBACCStructureVersion 0xF1BA Name: RBACCStructureVersion Byte Data #1 : #2 RBACC Structure Version 2-Bytes- A_BYTEFIELD M : M : 0x00 : 0x00 INFO_UDS 0007 Information on RBACC can be found in CVS151.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.2.1.31 DID 0xF1BA RBACCStructureVersion REQ_UDS 0037 Table 36 – Description of DID 0xF1BA RBACCStructureVersion 0xF1BA Name: RBACCStructureVersion Byte Data #1 : #2 RBACC Structure Version 2-Bytes- A_BYTEFIELD M : M : 0x00 : 0x00 INFO_UDS 0007 Information on RBACC can be found in CVS151. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 22 · page 22 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0038 | 5.2.1.32 DID 0xF1D1 RootCertificateIdentifierTable 37 – Description of DID 0xF1D1 RootCertificateIdentifier 0xF1D1 Name: RootCertificateIdentifier Byte DataExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.2.1.32 DID 0xF1D1 RootCertificateIdentifier REQ_UDS 0038 Table 37 – Description of DID 0xF1D1 RootCertificateIdentifier 0xF1D1 Name: RootCertificateIdentifier Byte Data Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 22 · page 22 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling High, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0039 | 32-Bytes A_BYTEFIEL D M : M 0x00 – 0xFF 0x20 5.2.1.33 DID 0xF1E1 vehicleManufacturerECUBootSoftwareNumberTable 38 – Description of DID 0xF1E1 vehicleManufacturerECUBootSoftwareNumber 0xF1E1 Name: vehicleManufacturerECUBootSoftwareNumber Byte No: Description Format Cvt Byte Value Default Data #1 : #13 vehicleManufacturer ECUBootSoftwareNu mber Byte #2 : 13-Byte- G, M : M : Project REQ_UDS 0238 This DID shall be stored under flash memory module in flash memory.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Hardware platform support; Secure software update and flash readiness Architecture: Hardware Platform SSR: SSR-UPD-002 | High Proposal Ready Open point: - | DetailsFull requirement text 32-Bytes A_BYTEFIEL D M : M 0x00 – 0xFF 0x20 5.2.1.33 DID 0xF1E1 vehicleManufacturerECUBootSoftwareNumber REQ_UDS 0039 Table 38 – Description of DID 0xF1E1 vehicleManufacturerECUBootSoftwareNumber 0xF1E1 Name: vehicleManufacturerECUBootSoftwareNumber Byte No: Description Format Cvt Byte Value Default Data #1 : #13 vehicleManufacturer ECUBootSoftwareNu mber Byte #2 : 13-Byte- G, M : M : Project REQ_UDS 0238 This DID shall be stored under flash memory module in flash memory. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-UPD-002 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 23 · page 23 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Medium, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0040 | 5.3 Diagnostic sessions requirementsA default diagnostic session shall be supported.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Validate assumption with customer; complete mapping; implement. | Diagnostic security | Feature / interface: Diagnostic security Architecture: Security Services SSR: SSR-RBAC-001 | High Proposal Ready Open point: - | DetailsFull requirement text 5.3 Diagnostic sessions requirements REQ_UDS 0040 A default diagnostic session shall be supported. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Diagnostic security | Security capability: Diagnostic security | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 23 · page 23 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0041 | The default diagnostic session is referred to as “defaultSession”.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0041 The default diagnostic session is referred to as “defaultSession”. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 23 · page 23 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Medium, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0042 | A non-default diagnostic session referred to as “extendedDiagnosticSession” shall be supported.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Validate assumption with customer; complete mapping; implement. | Diagnostic security | Feature / interface: Diagnostic security Architecture: Security Services SSR: SSR-RBAC-001 | High Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0042 A non-default diagnostic session referred to as “extendedDiagnosticSession” shall be supported. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Diagnostic security | Security capability: Diagnostic security | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 23 · page 23 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0043 | Diagnostic sessions not defined in this document shall be agreed with the vehicle manufacturer.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Validate assumption with customer; complete mapping; implement. | Diagnostic security | Feature / interface: Diagnostic security / OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface SSR: SSR-RBAC-001 | High Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0043 Diagnostic sessions not defined in this document shall be agreed with the vehicle manufacturer. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Diagnostic security | Security capability: Diagnostic security | Interface: OEM/Customer Review Interface | Architecture: Security Services; OEM/Customer Review Interface | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 23 · page 23 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0044 | Of a marked service, an execution shall be implemented for the specified session as perTable 39.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0044 Of a marked service, an execution shall be implemented for the specified session as perTable 39. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 23 · page 23 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0045 | Internal Page 24 (90)Table 39 – Diagnostic service support Service according to ISO 14229-1 Addressin g mode Application Boot loader Def Def Extd Prg Extd DiagnosticSessionControl (0x10) F, P M M M M M ECUReset (0x11) F, P M M M M M SecurityAccess (0x27) - - - - - CommunicationControl (0x28) F, P - M - - M TesterPresent (0x3E) F, P M M M M M AccessTimingParameter (0x83) - - - - - Authentication (0x29) F, P M M M M M SecuredDataTransmission (0x84) P M M M M M ControlDTCSetting (0x85) F, P - M - - M LinkControl (0x87) - C - C C ReadDataByIdentifier (0x22) F, P M M M M M ReadMemoryByAddress (0x23) - - - - - ReadScalingDataByIdentifier (0x24) - - - - - ReadDataByPeriodicIdentifier (0x2A) - - - - - DynamicallyDefineDataIdentifier (0x2C) P U U - - - WriteDataByIdentifier (0x2E) P - M - M C WriteMemoryByAddress (0x3D) - - - - - ClearDiagnosticInformation (0x14) F, P M M - - - ReadDTCInformation (0x19) F, P M M - - - InputOutputControlByIdentifier (0x2F) P - C - - - RoutineControl (0x31) P M M - M M RequestDownload (0x34) P - C - C1 C1 RequestUpload (0x35) P - C - - - TransferData (0x36) P - C - M C RequestTransferExit (0x37) P - C - M C RequestFileTransfer (0x38) P - C - C1 C1 C1 = Either 0x34 or 0x38 is mandatory depending on file based or memory based ECU system.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | High Proposal Ready Open point: - | DetailsFull requirement text Internal Page 24 (90) REQ_UDS 0045 Table 39 – Diagnostic service support Service according to ISO 14229-1 Addressin g mode Application Boot loader Def Def Extd Prg Extd DiagnosticSessionControl (0x10) F, P M M M M M ECUReset (0x11) F, P M M M M M SecurityAccess (0x27) - - - - - CommunicationControl (0x28) F, P - M - - M TesterPresent (0x3E) F, P M M M M M AccessTimingParameter (0x83) - - - - - Authentication (0x29) F, P M M M M M SecuredDataTransmission (0x84) P M M M M M ControlDTCSetting (0x85) F, P - M - - M LinkControl (0x87) - C - C C ReadDataByIdentifier (0x22) F, P M M M M M ReadMemoryByAddress (0x23) - - - - - ReadScalingDataByIdentifier (0x24) - - - - - ReadDataByPeriodicIdentifier (0x2A) - - - - - DynamicallyDefineDataIdentifier (0x2C) P U U - - - WriteDataByIdentifier (0x2E) P - M - M C WriteMemoryByAddress (0x3D) - - - - - ClearDiagnosticInformation (0x14) F, P M M - - - ReadDTCInformation (0x19) F, P M M - - - InputOutputControlByIdentifier (0x2F) P - C - - - RoutineControl (0x31) P M M - M M RequestDownload (0x34) P - C - C1 C1 RequestUpload (0x35) P - C - - - TransferData (0x36) P - C - M C RequestTransferExit (0x37) P - C - M C RequestFileTransfer (0x38) P - C - C1 C1 C1 = Either 0x34 or 0x38 is mandatory depending on file based or memory based ECU system. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Cybersecurity control (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 24 · page 24 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00540 | Internal Page 25 (90) INFO_UDS 0038 In Table 39, bootloader sessions should only be applicable to Software updateable ECUs.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior; Secure software update and flash readiness Architecture: Application Software SSR: SSR-BOOT-001 | High Proposal Ready Open point: - | DetailsFull requirement text Internal Page 25 (90) INFO_UDS 0038 In Table 39, bootloader sessions should only be applicable to Software updateable ECUs. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-BOOT-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 25 · page 25 Estimation / resource / tool / IT / hardware impact Effort High, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0046 | The mapping of RoutineControl service routines to sessions shall be discussed and agreed with the vehicle manufacturer.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior / OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface SSR: SSR-DIAG-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0046 The mapping of RoutineControl service routines to sessions shall be discussed and agreed with the vehicle manufacturer. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Application Software; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 25 · page 25 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0047 | The server shall implement support for RBAC (Role Based Access Control) based on CVS151.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text REQ_UDS 0047 The server shall implement support for RBAC (Role Based Access Control) based on CVS151. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 25 · page 25 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0048 | CVS31 and CVS32 requirements preconditions per service shall be defined by the RBAC Configuration file in the ECU.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-RBAC-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0048 CVS31 and CVS32 requirements preconditions per service shall be defined by the RBAC Configuration file in the ECU. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-RBAC-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 25 · page 25 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0049 | Diagnostics safe state is the following conditions that needs be satisfied to ensure vehicle is not in operation while performing certain diagnostics services.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0049 Diagnostics safe state is the following conditions that needs be satisfied to ensure vehicle is not in operation while performing certain diagnostics services. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 25 · page 25 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0050 | The conditions that shall be checked are • Vehicle speed ~ 0 • Engine speed ~ 0 (for vehicles with IC engines) • High Voltage system disengaged ( for vehicles with high Voltage battery system) • Gear Box in neutral • Parking brake engaged INFO_UDS 0008 Diagnostics safe state is not intended for ensuring the vehicle safety rather its conditions that are checked to prevent executing Diagnostics services during vehicle operation Diagnostics safe state shall be checked before executing the diagnostics services as per Table 40.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | High Proposal Ready Open point: - | DetailsFull requirement text The conditions that shall be checked are • Vehicle speed ~ 0 • Engine speed ~ 0 (for vehicles with IC engines) • High Voltage system disengaged ( for vehicles with high Voltage battery system) • Gear Box in neutral • Parking brake engaged INFO_UDS 0008 Diagnostics safe state is not intended for ensuring the vehicle safety rather its conditions that are checked to prevent executing Diagnostics services during vehicle operation REQ_UDS 0050 Diagnostics safe state shall be checked before executing the diagnostics services as per Table 40. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 25 · page 25 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Medium, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0051 | Internal Page 26 (90) Diagnostics Service Diag Safe state check Application Boot loader TransferData (0x36) MRequestFileTransfer (0x38) M - C1 = Mandatory except for going to default session C2 = Based on recommendation from Safety Team C3 = Needs to be defined at each individual routines The server implementation shall comply with the following state diagram and the following state transition descriptions (P1 and P2 flags should be seen as implementation hints).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Needs Customer Clarification | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Send linked open point to the customer for decision. | None | Feature / interface: Application software behavior; System behavior; Secure software update and flash readiness Architecture: Application Software SSR: None | High Reviewed Internally Open point: OP-002 | DetailsFull requirement text Internal Page 26 (90) Diagnostics Service Diag Safe state check Application Boot loader TransferData (0x36) M - RequestFileTransfer (0x38) M - C1 = Mandatory except for going to default session C2 = Based on recommendation from Safety Team C3 = Needs to be defined at each individual routines REQ_UDS 0051 The server implementation shall comply with the following state diagram and the following state transition descriptions (P1 and P2 flags should be seen as implementation hints). Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Flagged customer_clarification_needed=yes during extraction. Implementation approach Hold implementation; raise an open point and a clarification question. Acceptance condition Customer answers the linked open point. Customer feedback - Customer decision - Customer clarification / open point Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. Traceability Feature: Application software behavior; System behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 26 · page 26 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Medium, IT High, HW/Test Low Risk if unresolved Scope and effort cannot be frozen; estimation carries an open assumption and downstream design may rework. Next action Send linked open point to the customer for decision. |
| REQ_UDS-0338 | Internal Page 27 (90) Figure 2 -State DiagramThe session transitions stated below shall be possible to request both physically or functionally addressed to the server, otherwise the applicable addressing method is stated for the explicit transition.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-DIAG-003 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text Internal Page 27 (90) Figure 2 -State Diagram REQ_UDS 0338 The session transitions stated below shall be possible to request both physically or functionally addressed to the server, otherwise the applicable addressing method is stated for the explicit transition. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-DIAG-003 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 27 · page 27 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0305 | INFO_UDS 0019 Description of the individual transitions as per Figure 2 -State Diagram is explained fromto REQ_UDS 0337.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text INFO_UDS 0019 Description of the individual transitions as per Figure 2 -State Diagram is explained from REQ_UDS 0305 to REQ_UDS 0337. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 27 · page 27 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0306 | Internal Page 28 (90)2.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text Internal Page 28 (90) REQ_UDS 0306 2. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 28 · page 28 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0316 | Internal Page 29 (90)12.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text Internal Page 29 (90) REQ_UDS 0316 12. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 29 · page 29 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0328 | Internal Page 30 (90)24.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text Internal Page 30 (90) REQ_UDS 0328 24. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 30 · page 30 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0052 | Internal Page 31 (90) 5.4 Data identifier requirementsProject specific DID shall be added to ranges defined as system supplier specific in ISO 14229- 1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: Compliance Process; OEM/Customer Review Interface SSR: SSR-DIAG-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text Internal Page 31 (90) 5.4 Data identifier requirements REQ_UDS 0052 Project specific DID shall be added to ranges defined as system supplier specific in ISO 14229- 1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Compliance Process; OEM/Customer Review Interface | Work product: DIA / cybersecurity case | SSR: SSR-DIAG-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 31 · page 31 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0053 | Table 41 lists reserved ECU DIDs/DID ranges which are not used for identification and which shall only be implemented in agreement with the vehicle manufacturer.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Hardware platform support / OEM/Customer Review Interface Architecture: Hardware Platform; OEM/Customer Review Interface SSR: SSR-DIAG-006 | Low Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0053 Table 41 lists reserved ECU DIDs/DID ranges which are not used for identification and which shall only be implemented in agreement with the vehicle manufacturer. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Hardware Platform; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-DIAG-006 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 31 · page 31 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0054 | These ECUs shall implement the following DIDs according to Table 42.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0054 These ECUs shall implement the following DIDs according to Table 42. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 31 · page 31 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0055 | Internal Page 32 (90) 5.5 Diagnostic services requirementsThe SPRMIB shall be supported for services as specified in (ISO 14229-1).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Validate assumption with customer; complete mapping; implement. | Diagnostic security | Feature / interface: Diagnostic security Architecture: Security Services SSR: SSR-RBAC-001 | High Proposal Ready Open point: - | DetailsFull requirement text Internal Page 32 (90) 5.5 Diagnostic services requirements REQ_UDS 0055 The SPRMIB shall be supported for services as specified in (ISO 14229-1). Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Diagnostic security | Security capability: Diagnostic security | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 32 · page 32 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0056 | Negative response codes specified in ISO 14229-1 Annex A.1 shall only be supported if explicitly specified by this specification or its normative references.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-DIAG-005 | Low Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0056 Negative response codes specified in ISO 14229-1 Annex A.1 shall only be supported if explicitly specified by this specification or its normative references. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-DIAG-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 32 · page 32 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0342 | Negative response code 0x22, conditionsNotCorrect , shall be used if a service request is denied due to insufficient rights according to the RBACC check.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-RBAC-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0342 Negative response code 0x22, conditionsNotCorrect , shall be used if a service request is denied due to insufficient rights according to the RBACC check. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-RBAC-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 32 · page 32 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0057 | 5.5.1 DiagnosticSessionControl (0x10) service 5.5.1.1 Request REQ_UDS 0239 5.5.1.1.1 Request parameter diagnosticSessionType - A DiagnosticSessionControl service request with parameter diagnosticSessionType set to ProgrammingSession shall be processed only if normal communication is currently switched off as a result of a previous call to the Communication Control service.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior; Secure software update and flash readiness Architecture: Application Software SSR: SSR-UPD-003 | High Proposal Ready Open point: - | DetailsFull requirement text 5.5.1 DiagnosticSessionControl (0x10) service 5.5.1.1 Request REQ_UDS 0239 5.5.1.1.1 Request parameter diagnosticSessionType REQ_UDS 0057 A DiagnosticSessionControl service request with parameter diagnosticSessionType set to ProgrammingSession shall be processed only if normal communication is currently switched off as a result of a previous call to the Communication Control service. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-UPD-003 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 32 · page 32 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Medium, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00559 | The application shall respond with NRC 0x22 (conditionsNotCorrect) if communication has not been switched off.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text The application shall respond with NRC 0x22 (conditionsNotCorrect) if communication has not been switched off. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 32 · page 32 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0058 | Table 43 – Service 0x10 request parameter diagnosticSessionType description Hex (bit 6-0) Description Cvt 0x01 defaultSession M 0x02 ProgrammingSession M 0x03 extendedDiagnosticSession M REQ_UDS 0059 Following an accepted request to switch to the ProgrammingSession, the application shall make all preparations to guarantee trouble-free programming operation.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior; Secure software update and flash readiness Architecture: Application Software SSR: SSR-UPD-003 | High Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0058 Table 43 – Service 0x10 request parameter diagnosticSessionType description Hex (bit 6-0) Description Cvt 0x01 defaultSession M 0x02 ProgrammingSession M 0x03 extendedDiagnosticSession M REQ_UDS 0059 Following an accepted request to switch to the ProgrammingSession, the application shall make all preparations to guarantee trouble-free programming operation. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-UPD-003 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 32 · page 32 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Medium, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00561 | In this process, it shall end all routines and functions that influence programming and ensure that the server checked for safe state conditions at minimal.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration; Secure software update and flash readiness Architecture: Backend and IT Systems SSR: SSR-UPD-005 | Medium Proposal Ready Open point: OP-004 | DetailsFull requirement text In this process, it shall end all routines and functions that influence programming and ensure that the server checked for safe state conditions at minimal. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-004 Traceability Feature: Backend and IT integration; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-UPD-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 32 · page 32 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0060 | Before switching to programming session, the server shall ensure the applicable conditions as per Table 76Programming preconditions is checked to ensure the vehicle is in safe condition.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration; Secure software update and flash readiness Architecture: Backend and IT Systems SSR: SSR-UPD-005 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text REQ_UDS 0060 Before switching to programming session, the server shall ensure the applicable conditions as per Table 76 - Programming preconditions is checked to ensure the vehicle is in safe condition. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Backend and IT integration; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-UPD-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 32 · page 32 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00563 | Its upto the ECU to include the conditions that are relevant for that particular ECU, but needs to be agreed with Vehicle Manufacturer.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text Its upto the ECU to include the conditions that are relevant for that particular ECU, but needs to be agreed with Vehicle Manufacturer. Engineering expectation Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 32 · page 32 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0061 | Internal Page 33 (90) 5.5.1.2 Positive response REQ_UDS 0240Positive response shall be sent before the actual switch in case switching to Programming session.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Secure software update and flash readiness Architecture: System Core SSR: SSR-UPD-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text Internal Page 33 (90) 5.5.1.2 Positive response REQ_UDS 0240 REQ_UDS 0061 Positive response shall be sent before the actual switch in case switching to Programming session. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-UPD-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 33 · page 33 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0241 | 5.5.1.2.1 Response parameter diagnosticSessionTypeResponse parameter diagnosticSessionType shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-DIAG-005 | High Proposal Ready Open point: - | DetailsFull requirement text 5.5.1.2.1 Response parameter diagnosticSessionType REQ_UDS 0241 Response parameter diagnosticSessionType shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-DIAG-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 33 · page 33 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Medium, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0242 | 5.5.1.2.2 Response parameter sessionParameterRecordResponse parameter sessionParameterRecord shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-DIAG-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.5.1.2.2 Response parameter sessionParameterRecord REQ_UDS 0242 Response parameter sessionParameterRecord shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-DIAG-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 33 · page 33 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0062 | 5.5.1.3 Negative response REQ_UDS 0243 5.5.2 ECUReset (0x11) serviceAn ECUReset shall not be executed if the vehicle safety can be compromised.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | Low Proposal Ready Open point: - | DetailsFull requirement text 5.5.1.3 Negative response REQ_UDS 0243 5.5.2 ECUReset (0x11) service REQ_UDS 0062 An ECUReset shall not be executed if the vehicle safety can be compromised. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 33 · page 33 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0063 | ECU shall execute the reset only after sending a positive response to the ECU reset service REQ_UDS 0064 After a final positive response has been sent for ECUReset the server is not allowed to respond to any diagnostic service requests (except ECU identification) until it has restarted and been re- initialized.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Diagnostic security | Feature / interface: Diagnostic security Architecture: Security Services SSR: SSR-RBAC-001 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text REQ_UDS 0063 ECU shall execute the reset only after sending a positive response to the ECU reset service REQ_UDS 0064 After a final positive response has been sent for ECUReset the server is not allowed to respond to any diagnostic service requests (except ECU identification) until it has restarted and been re- initialized. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Diagnostic security | Security capability: Diagnostic security | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 33 · page 33 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0065 | The server shall be available for ECU identification within one second after sending positive response message to an ECUReset request.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Hardware platform support Architecture: Hardware Platform SSR: SSR-DIAG-006 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text REQ_UDS 0065 The server shall be available for ECU identification within one second after sending positive response message to an ECUReset request. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Hardware platform support | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-DIAG-006 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 33 · page 33 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test High Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0066 | After ECU reset, ECU shall be restarted and re-initialized within 2sec.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Hardware platform support Architecture: Hardware Platform SSR: SSR-DIAG-006 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0066 After ECU reset, ECU shall be restarted and re-initialized within 2sec. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-DIAG-006 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 33 · page 33 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0067 | The maximum time it takes from the positive response is sent from the server until it responds to new requests shall be agreed with vehicle manufacturer and documented.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration / OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface SSR: SSR-DIAG-003 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text REQ_UDS 0067 The maximum time it takes from the positive response is sent from the server until it responds to new requests shall be agreed with vehicle manufacturer and documented. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Backend and IT integration | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Backend and IT Systems; OEM/Customer Review Interface | Work product: Requirement traceability record | SSR: SSR-DIAG-003 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 33 · page 33 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0068 | Internal Page 34 (90) 5.5.2.1 Request REQ_UDS 0244 5.5.2.1.1 Request parameter resetTypeTable 44 – Service 0x11 request parameter resetType description Hex (bit 6-0) Description Cvt 0x01 hardReset M 0x02 keyOffOnReset C C = If the server is connected to the ignition key REQ_UDS 0069 The ECUReset service with requestParameter value 0x01 (hardReset) shall simulate the power-on / start-up sequence performed after a server has been previously disconnected from its power supply (i.e.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Key management | Feature / interface: Key management Architecture: Security Services SSR: SSR-KEY-001 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text Internal Page 34 (90) 5.5.2.1 Request REQ_UDS 0244 5.5.2.1.1 Request parameter resetType REQ_UDS 0068 Table 44 – Service 0x11 request parameter resetType description Hex (bit 6-0) Description Cvt 0x01 hardReset M 0x02 keyOffOnReset C C = If the server is connected to the ignition key REQ_UDS 0069 The ECUReset service with requestParameter value 0x01 (hardReset) shall simulate the power-on / start-up sequence performed after a server has been previously disconnected from its power supply (i.e. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Key management | Security capability: Key management | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-KEY-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 34 · page 34 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00573 | the disconnect from the battery shall not be simulated.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Low Proposal Ready Open point: - | DetailsFull requirement text the disconnect from the battery shall not be simulated. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 34 · page 34 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00574 | The implementation of hardReset shall first ensure that data corruption will not occur.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text The implementation of hardReset shall first ensure that data corruption will not occur. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 34 · page 34 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0070 | The ECUReset service with requestParameter value 0x02 (keyOffOnReset) shall simulate the turning of the ignition key off and back on and shall ensure that the values of non-volatile memory locations are preserved and the volatile memory will be initialized.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | Key management | Feature / interface: Key management Architecture: Security Services SSR: SSR-KEY-001 | High Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0070 The ECUReset service with requestParameter value 0x02 (keyOffOnReset) shall simulate the turning of the ignition key off and back on and shall ensure that the values of non-volatile memory locations are preserved and the volatile memory will be initialized. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Key management | Security capability: Key management | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-KEY-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 34 · page 34 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0071 | The implementation of ECUReset service with requestParameter value 0x02 (keyOffOnReset) shall ensure that every server task is finished prior sending a positive response.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text REQ_UDS 0071 The implementation of ECUReset service with requestParameter value 0x02 (keyOffOnReset) shall ensure that every server task is finished prior sending a positive response. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 34 · page 34 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0072 | The implementation of ECUReset service with requestParameter value 0x02 (keyOffOnReset) shall ensure that the volatile memory buffered data is stored into non volatile memory prior sending a positive response.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | High Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0072 The implementation of ECUReset service with requestParameter value 0x02 (keyOffOnReset) shall ensure that the volatile memory buffered data is stored into non volatile memory prior sending a positive response. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 34 · page 34 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00578 | INFO_UDS 0010 The server shall send an ECUReset positive response message after the server tasks above are finished but before the server performs the actual resetType.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-DIAG-003 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text INFO_UDS 0010 The server shall send an ECUReset positive response message after the server tasks above are finished but before the server performs the actual resetType. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-DIAG-003 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 34 · page 34 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0073 | 5.5.2.2 Positive responseTable 45 – Service 0x11 positive response parameter description 1 ECUReset Response SID M 2 resetType MExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.5.2.2 Positive response REQ_UDS 0073 Table 45 – Service 0x11 positive response parameter description 1 ECUReset Response SID M 2 resetType M Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 34 · page 34 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0245 | Internal Page 35 (90) 5.5.2.2.1 Response parameter resetTypeResponse parameter resetType shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-DIAG-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text Internal Page 35 (90) 5.5.2.2.1 Response parameter resetType REQ_UDS 0245 Response parameter resetType shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-DIAG-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 35 · page 35 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0074 | 5.5.2.3 Negative response REQ_UDS 0246 5.5.2.3.1 Supported negative response codesTable 46 – Service 0x11 negative response codes NRC Description and scenario 0x12 sub-functionNotSupported Refer to ISO 14229-1 for scenario.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.5.2.3 Negative response REQ_UDS 0246 5.5.2.3.1 Supported negative response codes REQ_UDS 0074 Table 46 – Service 0x11 negative response codes NRC Description and scenario 0x12 sub-functionNotSupported Refer to ISO 14229-1 for scenario. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 35 · page 35 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0075 | 5.5.3 CommunicationControl (0x28) serviceServers involved in engine start shall not process CommunicationControl service requests until 2 seconds after terminal 15 goes active.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | Low Proposal Ready Open point: OP-002 | DetailsFull requirement text 5.5.3 CommunicationControl (0x28) service REQ_UDS 0075 Servers involved in engine start shall not process CommunicationControl service requests until 2 seconds after terminal 15 goes active. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 35 · page 35 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00583 | If a request is received before this time has passed the server shall respond with NRC 0x78 (requestCorrectlyReceived-ResponsePending) (and process the request and send a final response when 2 seconds have passed) or NRC 0x22 (conditionsNotCorrect).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-DIAG-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text If a request is received before this time has passed the server shall respond with NRC 0x78 (requestCorrectlyReceived-ResponsePending) (and process the request and send a final response when 2 seconds have passed) or NRC 0x22 (conditionsNotCorrect). Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-DIAG-003 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 35 · page 35 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ_UDS-0076 | INFO_UDS 0011 This requirement mitigates DOS (Denial Of Service) attacksWhen receiving CommunicationControl service request, Gateway server applications shall ensure quieting down of network to ECUs without diagnostic server which are present in their sub-buses REQ_UDS 0077 Safety conditions are project specific and shall be checked before accepting a request to disable communication.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Diagnostic security | Feature / interface: Diagnostic security Architecture: Security Services SSR: SSR-RBAC-001 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text INFO_UDS 0011 This requirement mitigates DOS (Denial Of Service) attacks REQ_UDS 0076 When receiving CommunicationControl service request, Gateway server applications shall ensure quieting down of network to ECUs without diagnostic server which are present in their sub-buses REQ_UDS 0077 Safety conditions are project specific and shall be checked before accepting a request to disable communication. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Diagnostic security | Security capability: Diagnostic security | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 35 · page 35 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00585 | INFO_UDS 0013 Communication control service should not only be used to improve the bandwidth situation during flashing /parametrisation but also for inhibiting systems in vehicle (like engine start) to ensure safety.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior; Secure software update and flash readiness Architecture: Application Software SSR: SSR-UPD-003 | High Proposal Ready Open point: - | DetailsFull requirement text INFO_UDS 0013 Communication control service should not only be used to improve the bandwidth situation during flashing /parametrisation but also for inhibiting systems in vehicle (like engine start) to ensure safety. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-UPD-003 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 36 · page 36 Estimation / resource / tool / IT / hardware impact Effort High, Competence Low, Tooling Medium, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0078 | 5.5.3.1 RequestTable 47 – Service 0x28 request parameter description 1 CommunicationControl Request SID M 2 controlType M 3 communicationType M 5.5.3.1.1 Request parameter controlType REQ_UDS 0079 Table 48 – Service 0x28 request parameter controlType description Hex (bit 6-0) Description Cvt 0x00 enableRxAndTx M 0x01 enableRxAndDisableTx M 0x40 – 0x5F vehicleManufacturerSpecific U 5.5.3.1.2 Request parameter communicationType REQ_UDS 0080 Table 49 – Service 0x28 request parameter communicationType description Bits Value (Hex) Description Cvt 0 -1 1 normalCommunicationMessages M 4 – 7 0 Disable / Enable specified communicationType M 5.5.3.2 Positive response REQ_UDS 0247 5.5.3.3 Negative response REQ_UDS 0248Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.5.3.1 Request REQ_UDS 0078 Table 47 – Service 0x28 request parameter description 1 CommunicationControl Request SID M 2 controlType M 3 communicationType M 5.5.3.1.1 Request parameter controlType REQ_UDS 0079 Table 48 – Service 0x28 request parameter controlType description Hex (bit 6-0) Description Cvt 0x00 enableRxAndTx M 0x01 enableRxAndDisableTx M 0x40 – 0x5F vehicleManufacturerSpecific U 5.5.3.1.2 Request parameter communicationType REQ_UDS 0080 Table 49 – Service 0x28 request parameter communicationType description Bits Value (Hex) Description Cvt 0 -1 1 normalCommunicationMessages M 4 – 7 0 Disable / Enable specified communicationType M 5.5.3.2 Positive response REQ_UDS 0247 5.5.3.3 Negative response REQ_UDS 0248 Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 36 · page 36 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0081 | Internal Page 37 (90) 5.5.4 TesterPresent (0x3E) service 5.5.4.1 General service requirementsIf the parameter suppressPosRespMsgIndicationBit = true in a functionally addressed request message, the service request shall not influence any ongoing physically addressed service request/response.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | Low Proposal Ready Open point: - | DetailsFull requirement text Internal Page 37 (90) 5.5.4 TesterPresent (0x3E) service 5.5.4.1 General service requirements REQ_UDS 0081 If the parameter suppressPosRespMsgIndicationBit = true in a functionally addressed request message, the service request shall not influence any ongoing physically addressed service request/response. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 37 · page 37 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00588 | INFO_UDS 0014 A functionally addressed TesterPresent may arrive at any time during another request.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | Low Proposal Ready Open point: - | DetailsFull requirement text INFO_UDS 0014 A functionally addressed TesterPresent may arrive at any time during another request. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 37 · page 37 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0249 | 5.5.4.2 RequestRequest format and parameter shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-DIAG-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.5.4.2 Request REQ_UDS 0249 Request format and parameter shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-DIAG-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 37 · page 37 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0250 | 5.5.4.3 Positive response5.5.4.4 Negative response REQ_UDS 0251 5.5.5 ControlDTCSetting (0x85) service REQ_UDS 0343 Servers shall reject a ControlDTCSetting service request (DTC setting type = off) with NRC 0x22 (conditionsNotCorrect) if programming preconditions are not satisfied.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior; Secure software update and flash readiness Architecture: Application Software SSR: SSR-UPD-003 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text 5.5.4.3 Positive response REQ_UDS 0250 5.5.4.4 Negative response REQ_UDS 0251 5.5.5 ControlDTCSetting (0x85) service REQ_UDS 0343 Servers shall reject a ControlDTCSetting service request (DTC setting type = off) with NRC 0x22 (conditionsNotCorrect) if programming preconditions are not satisfied. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Application software behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-UPD-003 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 37 · page 37 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0344 | The execution of this service in the application shall only impact the DTC settingdiagnostic tests for safety and degradations shall not be impacted (shall work as normal).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Validate assumption with customer; complete mapping; implement. | Diagnostic security | Feature / interface: Diagnostic security Architecture: Security Services SSR: SSR-RBAC-001 | High Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0344 The execution of this service in the application shall only impact the DTC setting - diagnostic tests for safety and degradations shall not be impacted (shall work as normal). Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Diagnostic security | Security capability: Diagnostic security | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 37 · page 37 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0345 | 5.5.5.1 RequestRefer to ISO 14229-1 for request format.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.5.5.1 Request REQ_UDS 0345 Refer to ISO 14229-1 for request format. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: DIA / cybersecurity case | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 37 · page 37 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0346 | 5.5.5.1.1 Request parameter DTCSettingTypeRefer to ISO 14229-1 for request parameter DTCSettingType.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.5.5.1.1 Request parameter DTCSettingType REQ_UDS 0346 Refer to ISO 14229-1 for request parameter DTCSettingType. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: DIA / cybersecurity case | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 37 · page 37 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0347 | Internal Page 38 (90) 5.5.5.1.2 Request parameter DTCSettingControlOptionRecordRefer to ISO 14229-1 for request parameter DTCSettingControlOptionRecord.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text Internal Page 38 (90) 5.5.5.1.2 Request parameter DTCSettingControlOptionRecord REQ_UDS 0347 Refer to ISO 14229-1 for request parameter DTCSettingControlOptionRecord. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: DIA / cybersecurity case | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 38 · page 38 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0348 | 5.5.5.2 Positive responseRefer to ISO 14229-1 for positive response format and parameter.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.5.5.2 Positive response REQ_UDS 0348 Refer to ISO 14229-1 for positive response format and parameter. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: DIA / cybersecurity case | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 38 · page 38 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0349 | 5.5.5.3 Negative responseRefer to ISO 14229-1 for negative response format and codes.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.5.5.3 Negative response REQ_UDS 0349 Refer to ISO 14229-1 for negative response format and codes. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: DIA / cybersecurity case | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 38 · page 38 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0082 | 5.5.6 Link Control (0x87) serviceThe server shall be able to switch baud rate within one second.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text 5.5.6 Link Control (0x87) service REQ_UDS 0082 The server shall be able to switch baud rate within one second. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 38 · page 38 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0083 | The boot loader shall inherit the selected baud rate if the LinkControl service request was received when the server was executing in the application.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-BOOT-001 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text REQ_UDS 0083 The boot loader shall inherit the selected baud rate if the LinkControl service request was received when the server was executing in the application. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-BOOT-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 38 · page 38 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0084 | Positive response shall be sent before the actual switch of the baud-rate takes place.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0084 Positive response shall be sent before the actual switch of the baud-rate takes place. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 38 · page 38 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0085 | Internal Page 39 (90) 5.5.6.1 Request 5.5.6.2 Request parameter linkControlTypeTable 50 – Service 0x87 request parameter linkControlType description Byte Value Description Cvt 0x01 verifyModeTransitionWithFixedParameter M 0x03 transitionMode M 0x40-0x5F vehicleManufacturerSpecific U 5.5.6.2.1 Request parameter linkControlModeIdentifier REQ_UDS 0086 Table 51 – Service 0x87 request parameter linkControlModeIdentifier description Byte Value Description Cvt 0x11 CAN250000Baud C 0x12 CAN500000Baud C 0x13 CAN1000000Baud C C = Baud rates shall be defined by the Project representative.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text Internal Page 39 (90) 5.5.6.1 Request 5.5.6.2 Request parameter linkControlType REQ_UDS 0085 Table 50 – Service 0x87 request parameter linkControlType description Byte Value Description Cvt 0x01 verifyModeTransitionWithFixedParameter M 0x03 transitionMode M 0x40-0x5F vehicleManufacturerSpecific U 5.5.6.2.1 Request parameter linkControlModeIdentifier REQ_UDS 0086 Table 51 – Service 0x87 request parameter linkControlModeIdentifier description Byte Value Description Cvt 0x11 CAN250000Baud C 0x12 CAN500000Baud C 0x13 CAN1000000Baud C C = Baud rates shall be defined by the Project representative. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 39 · page 39 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0087 | 5.5.6.3 Positive response REQ_UDS 0252 5.5.6.4 Negative Response REQ_UDS 0253 5.5.7 ReadDataByIdentifier (0x22) service 5.5.7.1 Request REQ_UDS 0254 If ECU supports request containing more than one data identifier it shall be documented (like in CDD, ODX etc).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.5.6.3 Positive response REQ_UDS 0252 5.5.6.4 Negative Response REQ_UDS 0253 5.5.7 ReadDataByIdentifier (0x22) service 5.5.7.1 Request REQ_UDS 0254 REQ_UDS 0087 If ECU supports request containing more than one data identifier it shall be documented (like in CDD, ODX etc). Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 39 · page 39 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0255 | 5.5.7.1.1 Request parameter dataIdentifierDataIdentifier parameter definition shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-DIAG-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.5.7.1.1 Request parameter dataIdentifier REQ_UDS 0255 DataIdentifier parameter definition shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-DIAG-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 39 · page 39 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0088 | Internal Page 40 (90)The data identifier ranges specified in Table 41 shall be followed.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text Internal Page 40 (90) REQ_UDS 0088 The data identifier ranges specified in Table 41 shall be followed. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 40 · page 40 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0089 | 5.5.7.2 Positive response REQ_UDS 0256 5.5.7.3 Negative response REQ_UDS 0257 5.5.8 WriteDataByIdentifier (0x2E) serviceThe sequence of writing data records with service 0x2E WriteDataByIdentifier shall be independent of any specific order REQ_UDS 0090 The range of a requested dataRecord value has to be checked by the server if the DID is safety relevant.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text 5.5.7.2 Positive response REQ_UDS 0256 5.5.7.3 Negative response REQ_UDS 0257 5.5.8 WriteDataByIdentifier (0x2E) service REQ_UDS 0089 The sequence of writing data records with service 0x2E WriteDataByIdentifier shall be independent of any specific order REQ_UDS 0090 The range of a requested dataRecord value has to be checked by the server if the DID is safety relevant. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 40 · page 40 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0091 | All changed data shall be valid and stored into non-volatile memory at the latest after an ECU Reset(0x11) subfunction 0x02 requested from client.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Hardware platform support Architecture: Hardware Platform SSR: SSR-DIAG-006 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0091 All changed data shall be valid and stored into non-volatile memory at the latest after an ECU Reset(0x11) subfunction 0x02 requested from client. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-DIAG-006 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 40 · page 40 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0092 | If it is necessary to force an explicit transfer of buffered data into non-volatile memory then this shall be supported both with ECU-Reset Service subfunction 0x02 and ignition (IGN) key Off/On (power cycle).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | Key management | Feature / interface: Key management Architecture: Security Services SSR: SSR-KEY-001 | High Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0092 If it is necessary to force an explicit transfer of buffered data into non-volatile memory then this shall be supported both with ECU-Reset Service subfunction 0x02 and ignition (IGN) key Off/On (power cycle). Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Key management | Security capability: Key management | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-KEY-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 40 · page 40 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0093 | Additional client requests which start copying RAM buffer data into non-volatile memory are not allowed.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0093 Additional client requests which start copying RAM buffer data into non-volatile memory are not allowed. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 40 · page 40 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00608 | If this action is necessary then it shall be integrated implicitly into ECU Reset (0x11) Service subfunction 0x02.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-008 | Medium Proposal Ready Open point: - | DetailsFull requirement text If this action is necessary then it shall be integrated implicitly into ECU Reset (0x11) Service subfunction 0x02. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-008 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 40 · page 40 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0258 | 5.5.8.1 RequestRequest format and parameter shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-DIAG-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.5.8.1 Request REQ_UDS 0258 Request format and parameter shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-DIAG-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 40 · page 40 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0259 | 5.5.8.2 Positive responseExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.5.8.2 Positive response REQ_UDS 0259 Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 40 · page 40 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0260 | Internal Page 41 (90) 5.5.8.3 Negative response5.5.9 ClearDiagnosticInformation (0x14) service 5.5.9.1 Request REQ_UDS 0261 5.5.9.1.1 Request parameter groupOfDTC REQ_UDS 0262 groupOfDTC parameter definition shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | High Proposal Ready Open point: - | DetailsFull requirement text Internal Page 41 (90) 5.5.8.3 Negative response REQ_UDS 0260 5.5.9 ClearDiagnosticInformation (0x14) service 5.5.9.1 Request REQ_UDS 0261 5.5.9.1.1 Request parameter groupOfDTC REQ_UDS 0262 groupOfDTC parameter definition shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 41 · page 41 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Medium, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0094 | 5.5.9.2 Positive response REQ_UDS 0263 5.5.9.3 Negative response REQ_UDS 0264 5.5.10 ReadDTCInformation (0x19) service 5.5.10.1 Request REQ_UDS 0265 5.5.10.1.1 Request parameter reportType Table 52 – Service 0x19 request parameter reportType description 0x01 reportNumberOfDTCByStatusMask M 0x02 reportDTCByStatusMask M 0x03 reportDTCSnapshotIdentification M 0x04 reportDTCSnapshotRecordByDTCNumber M 0x06 reportDTCExtendedDataRecordByDTCNumber M 0x0F reportMirrorMemoryDTCByStatusMask UExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.5.9.2 Positive response REQ_UDS 0263 5.5.9.3 Negative response REQ_UDS 0264 5.5.10 ReadDTCInformation (0x19) service 5.5.10.1 Request REQ_UDS 0265 5.5.10.1.1 Request parameter reportType REQ_UDS 0094 Table 52 – Service 0x19 request parameter reportType description 0x01 reportNumberOfDTCByStatusMask M 0x02 reportDTCByStatusMask M 0x03 reportDTCSnapshotIdentification M 0x04 reportDTCSnapshotRecordByDTCNumber M 0x06 reportDTCExtendedDataRecordByDTCNumber M 0x0F reportMirrorMemoryDTCByStatusMask U Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 41 · page 41 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0095 | Internal Page 42 (90) 0x10 reportMirrorMemoryDTCExtendedDataRecordByDTCNumber U 0x11 reportNumberOfMirrorMemoryDTCByStatusMask U 0x12 reportNumberOfEmissionsRelatedOBDDTCByStatusMask E 0x13 reportEmissionsRelatedOBDDTCByStatusMask E 0x42 reportWWHOBDDTCByMaskRecord E 0x55 reportWWHOBDDTCWithPermanentStatus E Legislated OBD relevant ECUs have to support legislated OBD standards.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text Internal Page 42 (90) 0x10 reportMirrorMemoryDTCExtendedDataRecordByDTCNumber U 0x11 reportNumberOfMirrorMemoryDTCByStatusMask U 0x12 reportNumberOfEmissionsRelatedOBDDTCByStatusMask E 0x13 reportEmissionsRelatedOBDDTCByStatusMask E 0x42 reportWWHOBDDTCByMaskRecord E 0x55 reportWWHOBDDTCWithPermanentStatus E REQ_UDS 0095 Legislated OBD relevant ECUs have to support legislated OBD standards. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 42 · page 42 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0266 | 5.5.10.1.2 Request parameter reportNumberOfDTCByStatusMaskReportNumberOfDTCByStatusMask parameter format shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-DIAG-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.5.10.1.2 Request parameter reportNumberOfDTCByStatusMask REQ_UDS 0266 ReportNumberOfDTCByStatusMask parameter format shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-DIAG-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 42 · page 42 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0267 | 5.5.10.1.3 Request parameter DTCStatusMaskDTCStatusMask parameter format shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-DIAG-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.5.10.1.3 Request parameter DTCStatusMask REQ_UDS 0267 DTCStatusMask parameter format shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-DIAG-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 42 · page 42 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0096 | 5.5.10.1.4 Request parameter DTCMaskRecordTable 53 – Service 0x19 request parameter DTCMaskRecord description Byte Description Cvt High Definition according to either ISO 15031-6, ISO 14229 vehicle- manufacturer-defined, SAE J1939-73 M Middle M Low M REQ_UDS 0097 It shall be mandatory to utilize SPNs & FMIs according to SAE J1939.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.5.10.1.4 Request parameter DTCMaskRecord REQ_UDS 0096 Table 53 – Service 0x19 request parameter DTCMaskRecord description Byte Description Cvt High Definition according to either ISO 15031-6, ISO 14229 vehicle- manufacturer-defined, SAE J1939-73 M Middle M Low M REQ_UDS 0097 It shall be mandatory to utilize SPNs & FMIs according to SAE J1939. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 42 · page 42 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0268 | 5.5.10.1.5 Request parameter DTCSnapshotRecordNumberDTCSnapshotRecordNumber parameter format shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-DIAG-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.5.10.1.5 Request parameter DTCSnapshotRecordNumber REQ_UDS 0268 DTCSnapshotRecordNumber parameter format shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-DIAG-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 42 · page 42 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0098 | Internal Page 43 (90) 5.5.10.1.6 Request parameter DTCExtDataRecordNumberTable 54 – Service 0x19 request parameter DTCExtDataRecordNumber description 0x00 Reserved by ISO/SAE M 0x11 ExtDataRecNum 1 M 0x14 ExtDataRecNum 4 M 0xFE All legislated OBD stored DTCExtendedData records E 0xFF All stored DTCExtendedData records M 5.5.10.1.7 Request parameter FunctionalGroupIdentifier REQ_UDS 0269 Response parameter FunctionalGroupIdentifier shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text Internal Page 43 (90) 5.5.10.1.6 Request parameter DTCExtDataRecordNumber REQ_UDS 0098 Table 54 – Service 0x19 request parameter DTCExtDataRecordNumber description 0x00 Reserved by ISO/SAE M 0x11 ExtDataRecNum 1 M 0x14 ExtDataRecNum 4 M 0xFE All legislated OBD stored DTCExtendedData records E 0xFF All stored DTCExtendedData records M 5.5.10.1.7 Request parameter FunctionalGroupIdentifier REQ_UDS 0269 Response parameter FunctionalGroupIdentifier shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 43 · page 43 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0270 | 5.5.10.1.8 Request parameter DTCSeverityMaskRecordDTCSeverityMaskRecord parameter format shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-DIAG-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.5.10.1.8 Request parameter DTCSeverityMaskRecord REQ_UDS 0270 DTCSeverityMaskRecord parameter format shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-DIAG-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 43 · page 43 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0271 | 5.5.10.1.9 Request parameter DTCSeverityMaskDTCSeverityMask parameter format shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-DIAG-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.5.10.1.9 Request parameter DTCSeverityMask REQ_UDS 0271 DTCSeverityMask parameter format shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-DIAG-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 43 · page 43 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0272 | 5.5.10.2 Positive response5.5.10.2.1 Response parameter DTCStatusAvailabilityMask REQ_UDS 0273 Response parameter DTCStatusAvailabilityMask shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-DIAG-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.5.10.2 Positive response REQ_UDS 0272 5.5.10.2.1 Response parameter DTCStatusAvailabilityMask REQ_UDS 0273 Response parameter DTCStatusAvailabilityMask shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-DIAG-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 43 · page 43 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0274 | 5.5.10.2.2 Response parameter DTCFormatIdentifierResponse parameter DTCFormatIdentifier shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-DIAG-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.5.10.2.2 Response parameter DTCFormatIdentifier REQ_UDS 0274 Response parameter DTCFormatIdentifier shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-DIAG-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 43 · page 43 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0275 | 5.5.10.2.3 Response parameter DTCCountResponse parameter DTCCount shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-DIAG-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.5.10.2.3 Response parameter DTCCount REQ_UDS 0275 Response parameter DTCCount shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-DIAG-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 43 · page 43 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0276 | Internal Page 44 (90) 5.5.10.2.4 Response parameter DTCAndStatusRecordResponse parameter DTCAndStatusRecord shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-DIAG-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text Internal Page 44 (90) 5.5.10.2.4 Response parameter DTCAndStatusRecord REQ_UDS 0276 Response parameter DTCAndStatusRecord shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-DIAG-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 44 · page 44 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0277 | 5.5.10.2.5 Response parameter DTCRecordResponse parameter DTCRecord shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-DIAG-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.5.10.2.5 Response parameter DTCRecord REQ_UDS 0277 Response parameter DTCRecord shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-DIAG-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 44 · page 44 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00626 | 5.5.10.2.6 Response parameter reportDTCSnapshotRecordByDTCNumber The snapshot data sub-function (0x04) shall have positive response message data and format as specified in Table 67.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-008 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.5.10.2.6 Response parameter reportDTCSnapshotRecordByDTCNumber The snapshot data sub-function (0x04) shall have positive response message data and format as specified in Table 67. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-008 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 44 · page 44 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0099 | Table 55 – Snapshot data sub-function (0x04) positive response message content and format Range tion #1 ReadDTCInformation Response SID = 0x59 M #2 reportType = [ reportDTCSnapshotRecordByDTCNumber ] = 0x04 M #3 : #6 DTCAndStatusRecord[] = [ Byte 1: DTCHighByte Byte 2: DTCMiddleByte Byte 3: DTCLowByte Byte 4: statusOfDTC 0xFF 0xFF 0xFF 0xFF M M M M #7 DTCSnapshotRecordNumber#1 This byte shall be set to value 0x01.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0099 Table 55 – Snapshot data sub-function (0x04) positive response message content and format Range tion #1 ReadDTCInformation Response SID = 0x59 M #2 reportType = [ reportDTCSnapshotRecordByDTCNumber ] = 0x04 M #3 : #6 DTCAndStatusRecord[] = [ Byte 1: DTCHighByte Byte 2: DTCMiddleByte Byte 3: DTCLowByte Byte 4: statusOfDTC 0xFF 0xFF 0xFF 0xFF M M M M #7 DTCSnapshotRecordNumber#1 This byte shall be set to value 0x01. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 44 · page 44 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00628 | If a mechanic is working on the vehicle, the driveline shall report Not Ready and place the vehicle in the state PropulsionNotReady.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text If a mechanic is working on the vehicle, the driveline shall report Not Ready and place the vehicle in the state PropulsionNotReady. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 46 · page 46 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00629 | Internal Page 49 (90) Range tion #54 ECU start-up and alive reasons Bits 0-3 (start-up reason): 0x0: Reserved 0x1: Primary wake-up (terminal 15 ON) 0x2: Secondary wake-up 0x3: Sub wake-up 1 0x4: Sub wake-up 2 0x5: Sub wake-up 3 0x6-0xE: Reserved 0xF: Not available Bits 4-7 (alive reason): 0x0: Reserved 0x1: Primary wake-up (terminal 15 ON) 0x2: Secondary wake-up 0x3: Sub wake-up 1 0x4: Sub wake-up 2 0x5: Sub wake-up 3 0x6: Stay alive 0x7-0xE: Reserved 0xF: Not available Note 1: While the reason for keeping the ECU alive may change during execution startup reason and alive reason are always identical at ECU startup.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | Low Proposal Ready Open point: - | DetailsFull requirement text Internal Page 49 (90) Range tion #54 ECU start-up and alive reasons Bits 0-3 (start-up reason): 0x0: Reserved 0x1: Primary wake-up (terminal 15 ON) 0x2: Secondary wake-up 0x3: Sub wake-up 1 0x4: Sub wake-up 2 0x5: Sub wake-up 3 0x6-0xE: Reserved 0xF: Not available Bits 4-7 (alive reason): 0x0: Reserved 0x1: Primary wake-up (terminal 15 ON) 0x2: Secondary wake-up 0x3: Sub wake-up 1 0x4: Sub wake-up 2 0x5: Sub wake-up 3 0x6: Stay alive 0x7-0xE: Reserved 0xF: Not available Note 1: While the reason for keeping the ECU alive may change during execution startup reason and alive reason are always identical at ECU startup. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Non-functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 49 · page 49 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT Low, HW/Test High Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00630 | dependent depend ent depende nt U #65+N+M- #66+N+M dataIdentifier 0x0000 – #67+N+M +P Data required by law or regulations Signal dependent depend ent depende nt C1 #68+N+M +P DTCSnapshotRecordNumber#2 (Latest Snapshot captured) 0x02 M #69+N+M +P DTCSnapshotRecordNumberOfIdentifiers#2 0x00 : 0xFF M #70+N+M +P : #70+2*(N +M+P) See specification for DTCSnapshotRecord[]#1 This latest snapshot shall contain the same type of data and format as DTCSnapshotRecord[]#1.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces / External Interfaces Architecture: External Interfaces SSR: SSR-DIAG-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text dependent depend ent depende nt U #65+N+M- #66+N+M dataIdentifier 0x0000 – #67+N+M +P Data required by law or regulations Signal dependent depend ent depende nt C1 #68+N+M +P DTCSnapshotRecordNumber#2 (Latest Snapshot captured) 0x02 M #69+N+M +P DTCSnapshotRecordNumberOfIdentifiers#2 0x00 : 0xFF M #70+N+M +P : #70+2*(N +M+P) See specification for DTCSnapshotRecord[]#1 This latest snapshot shall contain the same type of data and format as DTCSnapshotRecord[]#1. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-DIAG-007 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 50 · page 50 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0304 | DTCSnapshotRecordNumber#1 & DTCSnapshotRecordNumber#2 shall correspond to first time DTC happened and latest time DTC happened correspondingly.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0304 DTCSnapshotRecordNumber#1 & DTCSnapshotRecordNumber#2 shall correspond to first time DTC happened and latest time DTC happened correspondingly. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 50 · page 50 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0100 | Internal Page 51 (90) 5.5.10.2.7 Response parameter DTCExtDataRecordNumberTable 56 – Service 0x19 response parameter DTCExtDataRecordNumber description 0x00 Reserved by ISO/SAE M 0x11 ExtDataRecNum 1 M 0x14 ExtDataRecNum 4 M 0xFE All legislated OBD stored DTCExtendedData records E 0xFF All stored DTCExtendedData records M 5.5.10.2.8 Response parameter DTCExtDataRecord REQ_UDS 0101 The extended data sub-function (0x06) shall have the positive response message data and format specified in Table 68.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text Internal Page 51 (90) 5.5.10.2.7 Response parameter DTCExtDataRecordNumber REQ_UDS 0100 Table 56 – Service 0x19 response parameter DTCExtDataRecordNumber description 0x00 Reserved by ISO/SAE M 0x11 ExtDataRecNum 1 M 0x14 ExtDataRecNum 4 M 0xFE All legislated OBD stored DTCExtendedData records E 0xFF All stored DTCExtendedData records M 5.5.10.2.8 Response parameter DTCExtDataRecord REQ_UDS 0101 The extended data sub-function (0x06) shall have the positive response message data and format specified in Table 68. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 51 · page 51 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00633 | Table 57 – Extended data sub-function (0x06) positive response message content and format Byte Description Range Resolu tion #1 ReadDTCInformation Response SID = 0x59 M #2 reportType = reportDTCExtDataRecordByDTCNumber 0x06 M #3 : #6 DTCAndStatusRecord[] = [ DTCHighByte DTCMiddleByte DTCLowByte statusOfDTC ] M #7 DTCExtDataRecordNumber#1 This byte shall be set to value 0x11.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text Table 57 – Extended data sub-function (0x06) positive response message content and format Byte Description Range Resolu tion #1 ReadDTCInformation Response SID = 0x59 M #2 reportType = reportDTCExtDataRecordByDTCNumber 0x06 M #3 : #6 DTCAndStatusRecord[] = [ DTCHighByte DTCMiddleByte DTCLowByte statusOfDTC ] M #7 DTCExtDataRecordNumber#1 This byte shall be set to value 0x11. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 51 · page 51 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00634 | Internal Page 52 (90) Byte Description Range Resolu tion This byte shall be set to value 2 and is used to identify the response structure variant #9 Occurrence counter OCC, as described in section 5.7.2 [unsigned integer] 0..127 0 M #10 DTC priority 1 – Highest priority 2 - Second highest priority 3 – Lowest priority 255 – Unknown 1..3, 255 0xFF M #11..#16 Time/Date of the first DTC activation See Table 98 but without byte #7 and #8 M #17..#22 Time/Date of the latest DTC activation M #23..#26 ECU Operational hours at the first DTC activation [4-byte int, big endian] as described in section 5.7.5.2.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Needs Customer Clarification | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Send linked open point to the customer for decision. | None | Feature / interface: Hardware platform support Architecture: Hardware Platform SSR: None | Unknown Reviewed Internally Open point: OP-001 | DetailsFull requirement text Internal Page 52 (90) Byte Description Range Resolu tion This byte shall be set to value 2 and is used to identify the response structure variant #9 Occurrence counter OCC, as described in section 5.7.2 [unsigned integer] 0..127 0 M #10 DTC priority 1 – Highest priority 2 - Second highest priority 3 – Lowest priority 255 – Unknown 1..3, 255 0xFF M #11..#16 Time/Date of the first DTC activation See Table 98 but without byte #7 and #8 M #17..#22 Time/Date of the latest DTC activation M #23..#26 ECU Operational hours at the first DTC activation [4-byte int, big endian] as described in section 5.7.5.2. Engineering expectation Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Supplier proposal 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. Rationale Flagged customer_clarification_needed=yes during extraction. Implementation approach Hold implementation; raise an open point and a clarification question. Acceptance condition Customer answers the linked open point. Customer feedback - Customer decision - Customer clarification / open point Confirm the exact ECU designation/variant and the agreed item definition and boundary used for the risk analysis (TARA). Traceability Feature: Hardware platform support | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 52 · page 52 Estimation / resource / tool / IT / hardware impact Effort Unknown, Competence Medium, Tooling Medium, IT Low, HW/Test High Risk if unresolved Scope and effort cannot be frozen; estimation carries an open assumption and downstream design may rework. Next action Send linked open point to the customer for decision. |
| REQ-AUTO-00635 | For these ECUs these bytes shall contain default value 0xFF (all bytes).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text For these ECUs these bytes shall contain default value 0xFF (all bytes). Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 52 · page 52 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00636 | Internal Page 53 (90) Byte Description Range Resolu tion 0: 0 m 1: 5 m (factor 5) … 4261412863: 21 307 064 315 m #35..#38 Total vehicle distance at the latest DTC activation [4-byte int, big endian] in section 5.7.4.1 Not used for TRATON External engine and marine ECUsFor these ECUs these bytes shall contain default value 0xFF (all bytes).Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Medium Proposal Ready Open point: OP-004 | DetailsFull requirement text Internal Page 53 (90) Byte Description Range Resolu tion 0: 0 m 1: 5 m (factor 5) … 4261412863: 21 307 064 315 m #35..#38 Total vehicle distance at the latest DTC activation [4-byte int, big endian] in section 5.7.4.1 Not used for TRATON External engine and marine ECUsFor these ECUs these bytes shall contain default value 0xFF (all bytes). Engineering expectation Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-004 Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 53 · page 53 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00637 | 0: 0 m 1: 5 m (factor 5) … 4261412863: 21 307 064 315 m 0xFFF FFFFF 5 m/bit 0xFF (all bytes) C #41+(2p+1) +1 DTCExtDataRecordNumber#4 This byte shall be set to value 0x14.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 0: 0 m 1: 5 m (factor 5) … 4261412863: 21 307 064 315 m 0xFFF FFFFF 5 m/bit 0xFF (all bytes) C #41+(2p+1) +1 DTCExtDataRecordNumber#4 This byte shall be set to value 0x14. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 53 · page 53 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ_UDS-0278 | 5.5.10.2.9 Response parameter FunctionalGroupIdentifierResponse parameter FunctionalGroupIdentifier shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-DIAG-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.5.10.2.9 Response parameter FunctionalGroupIdentifier REQ_UDS 0278 Response parameter FunctionalGroupIdentifier shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-DIAG-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 53 · page 53 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0279 | 5.5.10.2.10 Response parameter DTCSeverityAvailabilityMaskResponse parameter DTCSeverityAvailabilityMask shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-DIAG-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.5.10.2.10 Response parameter DTCSeverityAvailabilityMask REQ_UDS 0279 Response parameter DTCSeverityAvailabilityMask shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-DIAG-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 53 · page 53 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0280 | Internal Page 54 (90) 5.5.10.2.11 Response parameter DTCAndSeverityRecordResponse parameter DTCAndSeverityRecord shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-DIAG-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text Internal Page 54 (90) 5.5.10.2.11 Response parameter DTCAndSeverityRecord REQ_UDS 0280 Response parameter DTCAndSeverityRecord shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-DIAG-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 54 · page 54 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0281 | 5.5.10.3 Negative response5.5.10.3.1 Supported negative response codes REQ_UDS 0282 Negative response codes shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-DIAG-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.5.10.3 Negative response REQ_UDS 0281 5.5.10.3.1 Supported negative response codes REQ_UDS 0282 Negative response codes shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-DIAG-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 54 · page 54 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0102 | 5.5.11 InputOutputControlByIdentifier (0x2F) service 5.5.11.1 Request REQ_UDS 0283 5.5.11.1.1 Request parameter dataIdentifier - The data identifier ranges specified in ISO 14229-1 shall be followed.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.5.11 InputOutputControlByIdentifier (0x2F) service 5.5.11.1 Request REQ_UDS 0283 5.5.11.1.1 Request parameter dataIdentifier REQ_UDS 0102 The data identifier ranges specified in ISO 14229-1 shall be followed. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 54 · page 54 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0103 | 5.5.11.1.2 Request parameter controlOptionRecordTable 58 – Service 0x2F request parameter controlOptionRecord description 1 inputOutputControlParameter M 2 ..Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.5.11.1.2 Request parameter controlOptionRecord REQ_UDS 0103 Table 58 – Service 0x2F request parameter controlOptionRecord description 1 inputOutputControlParameter M 2 .. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 54 · page 54 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0104 | 2 + (m-1) controlState byte 1 : controlState byte m C : C 5.5.11.1.3 Request parameter inputOutputControlParameterTable 59 – Service 0x2F request parameter inputOutputControlParameter description 0x00 returnControlToECU Refer to ISO 14229-1 for parameter description.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 2 + (m-1) controlState byte 1 : controlState byte m C : C 5.5.11.1.3 Request parameter inputOutputControlParameter REQ_UDS 0104 Table 59 – Service 0x2F request parameter inputOutputControlParameter description 0x00 returnControlToECU Refer to ISO 14229-1 for parameter description. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 54 · page 54 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0284 | M 5.5.11.1.4 Request parameter controlEnableMaskRecordControlEnableMaskRecord parameter format shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-DIAG-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text M 5.5.11.1.4 Request parameter controlEnableMaskRecord REQ_UDS 0284 ControlEnableMaskRecord parameter format shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-DIAG-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 55 · page 55 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0105 | 5.5.11.2 Positive response REQ_UDS 0285 5.5.11.3 Negative response REQ_UDS 0286 5.5.12 RoutineControl (0x31) service 5.5.12.1 Request REQ_UDS 0287 5.5.12.1.1 Request parameter RoutineControlType Table 60 – Service 0x31 request parameter RoutineControlType description 0x01 startRoutine M 0x02 stopRoutine C 0x03 requestRoutineResults C C = Mandatory for routines implemented according to Method “A”.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.5.11.2 Positive response REQ_UDS 0285 5.5.11.3 Negative response REQ_UDS 0286 5.5.12 RoutineControl (0x31) service 5.5.12.1 Request REQ_UDS 0287 5.5.12.1.1 Request parameter RoutineControlType REQ_UDS 0105 Table 60 – Service 0x31 request parameter RoutineControlType description 0x01 startRoutine M 0x02 stopRoutine C 0x03 requestRoutineResults C C = Mandatory for routines implemented according to Method “A”. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 55 · page 55 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0106 | 5.5.12.1.2 Request parameter RoutineIdentifierRequest parameter routineIdentifier shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-DIAG-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.5.12.1.2 Request parameter RoutineIdentifier REQ_UDS 0106 Request parameter routineIdentifier shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-DIAG-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 55 · page 55 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00648 | The routine IDs as listed in Table 61 are reserved by TRATON and shall not be used by the system supplier.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-005 | Low Proposal Ready Open point: - | DetailsFull requirement text The routine IDs as listed in Table 61 are reserved by TRATON and shall not be used by the system supplier. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 55 · page 55 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0107 | Internal Page 56 (90)Table 61 – Service 0x31 request parameter RoutineIdentifier description 0x02B2 0x02B3 0x02B4 ReadStatusOfDiagnosticEventCodes ReadDiagnosticEventCodesByStatus ReadEventCodeData These routine IDs are used to handle diagnostic event codes and only mandatory when these type of data are used.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | High Proposal Ready Open point: - | DetailsFull requirement text Internal Page 56 (90) REQ_UDS 0107 Table 61 – Service 0x31 request parameter RoutineIdentifier description 0x02B2 0x02B3 0x02B4 ReadStatusOfDiagnosticEventCodes ReadDiagnosticEventCodesByStatus ReadEventCodeData These routine IDs are used to handle diagnostic event codes and only mandatory when these type of data are used. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Cybersecurity control (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 56 · page 56 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0288 | 5.5.12.1.3 Request parameter RoutineControlOptionRecordRequest parameter routineControlOptionRecord shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-DIAG-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.5.12.1.3 Request parameter RoutineControlOptionRecord REQ_UDS 0288 Request parameter routineControlOptionRecord shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-DIAG-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 57 · page 57 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0108 | 5.5.12.2 Positive response REQ_UDS 0289 5.5.12.3 Negative response REQ_UDS 0290 5.5.13 Request Download Service (0x34)If the most recent Erase Memory routine request in the current session was made with the addressAndLengthFormatIdentifier parameter set to value 0x00 the server shall start erasing the memory area specified with the RequestDownload request.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text 5.5.12.2 Positive response REQ_UDS 0289 5.5.12.3 Negative response REQ_UDS 0290 5.5.13 Request Download Service (0x34) REQ_UDS 0108 If the most recent Erase Memory routine request in the current session was made with the addressAndLengthFormatIdentifier parameter set to value 0x00 the server shall start erasing the memory area specified with the RequestDownload request. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 57 · page 57 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00652 | INFO_UDS 0017 In order to satisfy stability requirements, the erasing of the boot loader may require that the old boot loader is copied into another memory area before the boot loader memory is erased, see Annex A for an implementation hint.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | Low Proposal Ready Open point: - | DetailsFull requirement text INFO_UDS 0017 In order to satisfy stability requirements, the erasing of the boot loader may require that the old boot loader is copied into another memory area before the boot loader memory is erased, see Annex A for an implementation hint. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Non-functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 57 · page 57 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0109 | If the most recent Erase Memory routine request in the current session was made with the addressAndLengthFormatIdentifier parameter set to value 0x00 the server shall reset the following identification DIDs to their default values: • If boot software download is requested, reset 0xF180, 0xF191 and 0xF187 to default values (some of the DIDs will be automatically erased as a consequence of erasing one or more modules).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text REQ_UDS 0109 If the most recent Erase Memory routine request in the current session was made with the addressAndLengthFormatIdentifier parameter set to value 0x00 the server shall reset the following identification DIDs to their default values: • If boot software download is requested, reset 0xF180, 0xF191 and 0xF187 to default values (some of the DIDs will be automatically erased as a consequence of erasing one or more modules). Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 57 · page 57 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0110 | Once the RequestDownload service has started, only services TesterPresent, ECUReset,TransferData and DiagnosticSessionControl shall be permitted until service RequestTransferExit has been called or until any of these services returns an error.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SDT-001 | High Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0110 Once the RequestDownload service has started, only services TesterPresent, ECUReset,TransferData and DiagnosticSessionControl shall be permitted until service RequestTransferExit has been called or until any of these services returns an error. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SDT-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 57 · page 57 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0111 | Internal Page 58 (90)If a non-permitted service is requested after the RequestDownload service has started and before RequestTransferExit has been called the server shall respond with NRC 0x12 (sub- functionNotSupported) and shall accept programming to proceed from the state at which it was executing before this non-permitted service was requested.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior; Secure software update and flash readiness Architecture: Application Software SSR: SSR-UPD-003 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text Internal Page 58 (90) REQ_UDS 0111 If a non-permitted service is requested after the RequestDownload service has started and before RequestTransferExit has been called the server shall respond with NRC 0x12 (sub- functionNotSupported) and shall accept programming to proceed from the state at which it was executing before this non-permitted service was requested. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Application software behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-UPD-003 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 58 · page 58 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0112 | 5.5.13.1 RequestThe server shall support service request formatted according to Table 62.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text 5.5.13.1 Request REQ_UDS 0112 The server shall support service request formatted according to Table 62. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 58 · page 58 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0113 | M 5.5.13.2 Request parameter dataFormatIdentifierTable 63 – Service 0x34 request parameter dataFormatIdentifier description compressionMethod: 0x0: no compression 0x1 – 0x9: reserved for the supplier 0xA: vehicle manufacturer standard compression algorithm LZSS 0xB – 0xF: reserved for vehicle manufacturer M 0x0 – 0xFExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text M 5.5.13.2 Request parameter dataFormatIdentifier REQ_UDS 0113 Table 63 – Service 0x34 request parameter dataFormatIdentifier description compressionMethod: 0x0: no compression 0x1 – 0x9: reserved for the supplier 0xA: vehicle manufacturer standard compression algorithm LZSS 0xB – 0xF: reserved for vehicle manufacturer M 0x0 – 0xF Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 58 · page 58 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0114 | Internal Page 59 (90) encryptingMethod: 0x0: no encryption 0x1: encryption on DSC 0x2 -0x7 : reserved for vehicle manufacturer M 0x0 – 0x1 5.5.13.3 Request parameter addressAndLengthFormatIdentifier Table 64 – Service 0x34 request parameter addressAndLengthFormatIdentifier description 7 - 4 Length (number of bytes) of the memorySize parameter M 3,4 3 - 0 Length (number of bytes) of the memoryAddress parameter M 3, 4 5.5.13.4 Positive response REQ_UDS 0115 Table 65 – Positive response parameter description #1 RequestDownload Response SID M 0x74 #2 lengthFormatIdentifier M 0x20 #3..Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text Internal Page 59 (90) encryptingMethod: 0x0: no encryption 0x1: encryption on DSC 0x2 -0x7 : reserved for vehicle manufacturer M 0x0 – 0x1 5.5.13.3 Request parameter addressAndLengthFormatIdentifier REQ_UDS 0114 Table 64 – Service 0x34 request parameter addressAndLengthFormatIdentifier description 7 - 4 Length (number of bytes) of the memorySize parameter M 3,4 3 - 0 Length (number of bytes) of the memoryAddress parameter M 3, 4 5.5.13.4 Positive response REQ_UDS 0115 Table 65 – Positive response parameter description #1 RequestDownload Response SID M 0x74 #2 lengthFormatIdentifier M 0x20 #3.. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 59 · page 59 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0116 | #4 maxNumberOfBlockLength[] = [ byte #1 (MSB) byte #2 ] M M 0xFF 0xFF 5.5.13.5 Response parameter lengthFormatIdentifierTable 66 – Service 0x34 response parameter lengthFormatIdentifier description 7 - 4 Length (number of bytes) of the maxNumberOfBlockLength parameter M 0x2 3 - 0 ISO reserved.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text #4 maxNumberOfBlockLength[] = [ byte #1 (MSB) byte #2 ] M M 0xFF 0xFF 5.5.13.5 Response parameter lengthFormatIdentifier REQ_UDS 0116 Table 66 – Service 0x34 response parameter lengthFormatIdentifier description 7 - 4 Length (number of bytes) of the maxNumberOfBlockLength parameter M 0x2 3 - 0 ISO reserved. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 59 · page 59 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0117 | Internal Page 60 (90) 5.5.14 RequestUpload (0x35) 5.5.14.1 RequestTable 67 – Service 0x35 request parameter description 1 RequestDownload Request SID M 2 dataFormatIdentifier M 3 addressAndLengthFormatIdentifier M 4 ..Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text Internal Page 60 (90) 5.5.14 RequestUpload (0x35) 5.5.14.1 Request REQ_UDS 0117 Table 67 – Service 0x35 request parameter description 1 RequestDownload Request SID M 2 dataFormatIdentifier M 3 addressAndLengthFormatIdentifier M 4 .. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 60 · page 60 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0118 | M 5.5.14.1.1 Request parameter dataFormatIdentifierTable 68 – Service 0x35 request parameter dataFormatIdentifier description Bytes Description Cvt Values compressionMethod: 0x0: no compression 0x1 – 0x9: reserved for the supplier 0xA: vehicle manufacturer standard compression algorithm LZSS 0xB – 0xF: reserved for vehicle manufacturer M 0x0 – 0xF encryptingMethod: 0x0: no encryption 0x1: encryption on DSC 0x2 -0x7 : reserved for vehicle manufacturer M 0x0 – 0x1Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text M 5.5.14.1.1 Request parameter dataFormatIdentifier REQ_UDS 0118 Table 68 – Service 0x35 request parameter dataFormatIdentifier description Bytes Description Cvt Values compressionMethod: 0x0: no compression 0x1 – 0x9: reserved for the supplier 0xA: vehicle manufacturer standard compression algorithm LZSS 0xB – 0xF: reserved for vehicle manufacturer M 0x0 – 0xF encryptingMethod: 0x0: no encryption 0x1: encryption on DSC 0x2 -0x7 : reserved for vehicle manufacturer M 0x0 – 0x1 Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 60 · page 60 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0119 | Internal Page 61 (90) 5.5.14.1.2 Request parameter addressAndLengthFormatIdentifierTable 69 – Service 0x35 request parameter addressAndLengthFormatIdentifier description 7 - 4 Length (number of bytes) of the memorySize parameter M 3,4 3 - 0 Length (number of bytes) of the memoryAddress parameter M 3, 4 5.5.14.1.3 Request parameter memoryAddress REQ_UDS 0291 MemoryAddress parameter definition shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text Internal Page 61 (90) 5.5.14.1.2 Request parameter addressAndLengthFormatIdentifier REQ_UDS 0119 Table 69 – Service 0x35 request parameter addressAndLengthFormatIdentifier description 7 - 4 Length (number of bytes) of the memorySize parameter M 3,4 3 - 0 Length (number of bytes) of the memoryAddress parameter M 3, 4 5.5.14.1.3 Request parameter memoryAddress REQ_UDS 0291 MemoryAddress parameter definition shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 61 · page 61 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0292 | 5.5.14.1.4 Request parameter memorySizeMemorySize parameter definition shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-DIAG-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.5.14.1.4 Request parameter memorySize REQ_UDS 0292 MemorySize parameter definition shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-DIAG-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 61 · page 61 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0120 | 5.5.14.2 Positive response REQ_UDS 0293 5.5.14.2.1 Response parameter lengthFormatIdentifierTable 70 – Service 0x35 response parameter lengthFormatIdentifier description 7 - 4 Length (number of bytes) of the maxNumberOfBlockLength parameter M 0x2 3 - 0 ISO reserved.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.5.14.2 Positive response REQ_UDS 0293 5.5.14.2.1 Response parameter lengthFormatIdentifier REQ_UDS 0120 Table 70 – Service 0x35 response parameter lengthFormatIdentifier description 7 - 4 Length (number of bytes) of the maxNumberOfBlockLength parameter M 0x2 3 - 0 ISO reserved. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 61 · page 61 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0294 | M 0 5.5.14.3 Negative responseRefer to ISO 14229-1 for negative response format and codes shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-DIAG-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text M 0 5.5.14.3 Negative response REQ_UDS 0294 Refer to ISO 14229-1 for negative response format and codes shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-DIAG-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 61 · page 61 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0295 | 5.5.15 TransferData (0x36) service 5.5.15.1 RequestExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.5.15 TransferData (0x36) service 5.5.15.1 Request REQ_UDS 0295 Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 61 · page 61 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0296 | Internal Page 62 (90) 5.5.15.1.1 Request parameter blockSequenceCounterMemoryAddress parameter definition shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-DIAG-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text Internal Page 62 (90) 5.5.15.1.1 Request parameter blockSequenceCounter REQ_UDS 0296 MemoryAddress parameter definition shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-DIAG-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 62 · page 62 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0297 | 5.5.15.1.2 Request parameter transferRequestParameterRecordMemorySize parameter definition shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-DIAG-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.5.15.1.2 Request parameter transferRequestParameterRecord REQ_UDS 0297 MemorySize parameter definition shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-DIAG-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 62 · page 62 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0121 | 5.5.15.2 Positive response REQ_UDS 0298 5.5.15.3 Negative response REQ_UDS 0299 5.5.15.3.1 Supported negative response codes REQ_UDS 0300 5.5.16 RequestTransferExit (0x37) service 5.5.16.1 Request Table 71 – Service 0x37 request parameter description 1 RequestTransferExit Request SID M 5.5.16.1.1 Request parameter transferRequestParameterRecord REQ_UDS 0122 The transferRequestParameterRecord shall not be supported.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | Low Proposal Ready Open point: - | DetailsFull requirement text 5.5.15.2 Positive response REQ_UDS 0298 5.5.15.3 Negative response REQ_UDS 0299 5.5.15.3.1 Supported negative response codes REQ_UDS 0300 5.5.16 RequestTransferExit (0x37) service 5.5.16.1 Request REQ_UDS 0121 Table 71 – Service 0x37 request parameter description 1 RequestTransferExit Request SID M 5.5.16.1.1 Request parameter transferRequestParameterRecord REQ_UDS 0122 The transferRequestParameterRecord shall not be supported. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 62 · page 62 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0123 | 5.5.16.2 Positive responseTable 72 – Service 0x37 positive response parameter description 1 RequestTransferExit Response SID MExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.5.16.2 Positive response REQ_UDS 0123 Table 72 – Service 0x37 positive response parameter description 1 RequestTransferExit Response SID M Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 62 · page 62 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0124 | Internal Page 63 (90) 5.5.16.2.1 Response parameter transferResponseParameterRecordThe transferRequestParameterRecord shall not be supported.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Low Proposal Ready Open point: - | DetailsFull requirement text Internal Page 63 (90) 5.5.16.2.1 Response parameter transferResponseParameterRecord REQ_UDS 0124 The transferRequestParameterRecord shall not be supported. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 63 · page 63 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0125 | 5.5.16.3 Negative response REQ_UDS 0301 5.5.16.3.1 Supported negative response codes REQ_UDS 0302 5.5.17 SecuredDataTransmission (0x84) service This service shall be used when transmitting data in a secured mode, see CVS32.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.5.16.3 Negative response REQ_UDS 0301 5.5.16.3.1 Supported negative response codes REQ_UDS 0302 5.5.17 SecuredDataTransmission (0x84) service REQ_UDS 0125 This service shall be used when transmitting data in a secured mode, see CVS32. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 63 · page 63 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0126 | 5.5.17.1 Request REQ_UDS 0303 5.5.17.1.1 Request message data-parameter definitionData parameter definition shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces / External Interfaces Architecture: External Interfaces SSR: SSR-DIAG-007 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.5.17.1 Request REQ_UDS 0303 5.5.17.1.1 Request message data-parameter definition REQ_UDS 0126 Data parameter definition shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-DIAG-007 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 63 · page 63 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0127 | 5.5.17.2 Positive responsePositive response shall be as per CVS32.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.5.17.2 Positive response REQ_UDS 0127 Positive response shall be as per CVS32. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 63 · page 63 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0128 | 5.5.17.3 Negative responseNegative response shall be as per CVS32 5.5.17.3.1 Supported negative response codes REQ_UDS 0129 Negative response format shall be as per ISO 14229-1 5.5.18 Authentication (0x29) service REQ_UDS 0130 Authentication (0x29) service shall be used for authentication of client and server.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-RBAC-004 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text 5.5.17.3 Negative response REQ_UDS 0128 Negative response shall be as per CVS32 5.5.17.3.1 Supported negative response codes REQ_UDS 0129 Negative response format shall be as per ISO 14229-1 5.5.18 Authentication (0x29) service REQ_UDS 0130 Authentication (0x29) service shall be used for authentication of client and server. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-RBAC-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 63 · page 63 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0133 | Internal Page 64 (90)The Authentication (0x29) service shall be implemented according to CVS31 .Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-RBAC-004 | High Proposal Ready Open point: - | DetailsFull requirement text Internal Page 64 (90) REQ_UDS 0133 The Authentication (0x29) service shall be implemented according to CVS31 . Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-RBAC-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 64 · page 64 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0134 | 5.5.18.1 RequestRefer to CVS31 .Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.5.18.1 Request REQ_UDS 0134 Refer to CVS31 . Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 64 · page 64 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0135 | 5.5.18.2 Request parameter subFunctionRefer to CVS31 .Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.5.18.2 Request parameter subFunction REQ_UDS 0135 Refer to CVS31 . Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 64 · page 64 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0136 | 5.5.18.3 Positive responseRefer to CVS31 .Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.5.18.3 Positive response REQ_UDS 0136 Refer to CVS31 . Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 64 · page 64 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0137 | 5.5.18.4 Negative response5.5.18.4.1 Supported negative response codes REQ_UDS 0138 Supported negative response codes shall be as per ISO 14229-1, especially the NRC range 0x50 – 0x5D according to Table 73.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-DIAG-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.5.18.4 Negative response REQ_UDS 0137 5.5.18.4.1 Supported negative response codes REQ_UDS 0138 Supported negative response codes shall be as per ISO 14229-1, especially the NRC range 0x50 – 0x5D according to Table 73. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-DIAG-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 64 · page 64 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0139 | Internal Page 65 (90)For detailed error cases and the mapping to the corresponding NRCs the Authentication service implementation specification CVS31 shall be used.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | High Proposal Ready Open point: - | DetailsFull requirement text Internal Page 65 (90) REQ_UDS 0139 For detailed error cases and the mapping to the corresponding NRCs the Authentication service implementation specification CVS31 shall be used. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 65 · page 65 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0140 | 5.5.19 RequestFileTransfer (0x38) service 5.5.19.1 Request5.5.19.2 Request Parameter modeOfOperation REQ_UDS 0141 Table 74 – Service 0x38 request parameter modeOfOperation description Byte value Description Cvt 0x00 ISO Reserved M 0x01 AddFile This value shall be used to add the file (download) defined in the filePathAndName parameter M 0x02 DeleteFile This value shall be used to delete the file defined in the filePathAndName parameter U 0x03 ReplaceFile This value shall be used to replace the file (download) defined in the filePathAndName parameter.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.5.19 RequestFileTransfer (0x38) service 5.5.19.1 Request REQ_UDS 0140 5.5.19.2 Request Parameter modeOfOperation REQ_UDS 0141 Table 74 – Service 0x38 request parameter modeOfOperation description Byte value Description Cvt 0x00 ISO Reserved M 0x01 AddFile This value shall be used to add the file (download) defined in the filePathAndName parameter M 0x02 DeleteFile This value shall be used to delete the file defined in the filePathAndName parameter U 0x03 ReplaceFile This value shall be used to replace the file (download) defined in the filePathAndName parameter. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 65 · page 65 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00683 | If the file is not stored at the location the file shall be added.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text If the file is not stored at the location the file shall be added. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 65 · page 65 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00684 | M 0x04 ReadFile This value shall be used to read the file (upload) at the location defined by the filePathAndName parameter.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text M 0x04 ReadFile This value shall be used to read the file (upload) at the location defined by the filePathAndName parameter. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 65 · page 65 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00685 | U 0x05 ReadDir This value shall be used to read the directory defined in the filePathAndName parameter.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text U 0x05 ReadDir This value shall be used to read the directory defined in the filePathAndName parameter. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 65 · page 65 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00686 | U 0x06 ResumeFile This value shall be used to resume downloading the file defined in the filePathAndName parameter at the returned filePosition indicator.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text U 0x06 ResumeFile This value shall be used to resume downloading the file defined in the filePathAndName parameter at the returned filePosition indicator. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 65 · page 65 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00687 | The file specified in the filePathAndName shall already exist in the ECU’s file system.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Hardware platform support Architecture: Hardware Platform SSR: SSR-HW-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text The file specified in the filePathAndName shall already exist in the ECU’s file system. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-HW-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 65 · page 65 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ_UDS-0142 | Internal Page 66 (90) Byte value Description Cvt 0x07 – 0xFF ISO Reserved M 5.5.19.3 Request parameter subFunctionRefer to ISO 14229-1 for parameter sub-function format shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text Internal Page 66 (90) Byte value Description Cvt 0x07 – 0xFF ISO Reserved M 5.5.19.3 Request parameter subFunction REQ_UDS 0142 Refer to ISO 14229-1 for parameter sub-function format shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 66 · page 66 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0143 | 5.5.19.4 Request Parameter dataFormatIdentifierTable 75 – Service 0x38 request parameter dataFormatIdentifier description compressionMethod: 0x0: no compression 0x1 – 0x9: reserved for the supplier 0xA: vehicle manufacturer standard compression algorithm LZSS 0xB – 0xF: reserved for vehicle manufacturer M 0x0 – 0xF encryptingMethod: 0x0: no encryption 0x1: encryption on DSC 0x2 -0x7 : reserved for vehicle manufacturer M 0x0 – 0x1 5.5.19.5 Positive response REQ_UDS 0144 5.5.19.6 Negative response REQ_UDS 0145 5.5.19.7 Supported negative response codes REQ_UDS 0146 Supported negative response codes shall be as per ISO 14229-1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior / OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface SSR: SSR-DIAG-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.5.19.4 Request Parameter dataFormatIdentifier REQ_UDS 0143 Table 75 – Service 0x38 request parameter dataFormatIdentifier description compressionMethod: 0x0: no compression 0x1 – 0x9: reserved for the supplier 0xA: vehicle manufacturer standard compression algorithm LZSS 0xB – 0xF: reserved for vehicle manufacturer M 0x0 – 0xF encryptingMethod: 0x0: no encryption 0x1: encryption on DSC 0x2 -0x7 : reserved for vehicle manufacturer M 0x0 – 0x1 5.5.19.5 Positive response REQ_UDS 0144 5.5.19.6 Negative response REQ_UDS 0145 5.5.19.7 Supported negative response codes REQ_UDS 0146 Supported negative response codes shall be as per ISO 14229-1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Application Software; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 66 · page 66 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0147 | Internal Page 67 (90)The programming preconditions shall be agreed with the vehicle manufacturer.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Secure software update and flash readiness / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-UPD-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text Internal Page 67 (90) REQ_UDS 0147 The programming preconditions shall be agreed with the vehicle manufacturer. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Secure software update and flash readiness | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-UPD-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 67 · page 67 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00691 | Preconditions to be discussed with the vehicle manufacturer shall include but not be limited to Diag safe state conditions.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-005 | Low Proposal Ready Open point: OP-009 | DetailsFull requirement text Preconditions to be discussed with the vehicle manufacturer shall include but not be limited to Diag safe state conditions. Engineering expectation Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-009 Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 67 · page 67 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0148 | The decision on conditions of the programming precondition shall be based on minimum two independent sources of information.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Secure software update and flash readiness Architecture: System Core SSR: SSR-UPD-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0148 The decision on conditions of the programming precondition shall be based on minimum two independent sources of information. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-UPD-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 67 · page 67 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0149 | If information is not available for checking a programming precondition the programming precondition shall be considered fulfilled.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Secure software update and flash readiness Architecture: System Core SSR: SSR-UPD-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0149 If information is not available for checking a programming precondition the programming precondition shall be considered fulfilled. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-UPD-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 67 · page 67 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00694 | If the ECU received the information related to any of the conditions during the same driving cycle then it shall use that information.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Hardware platform support Architecture: Hardware Platform SSR: SSR-HW-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text If the ECU received the information related to any of the conditions during the same driving cycle then it shall use that information. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-HW-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 67 · page 67 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ_UDS-0150 | This routine shall be supported in Extended session of both Application and Boot.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0150 This routine shall be supported in Extended session of both Application and Boot. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 67 · page 67 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0151 | 5.6.1.1 Request 5.6.1.2 Request parameter RoutineControlOptionRecordRequest parameter RoutineControlOptionRecord shall not be supported.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Low Proposal Ready Open point: - | DetailsFull requirement text 5.6.1.1 Request 5.6.1.2 Request parameter RoutineControlOptionRecord REQ_UDS 0151 Request parameter RoutineControlOptionRecord shall not be supported. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 67 · page 67 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0152 | Request parameter routineControlType with value 0x03 (requestRoutineResults) shall not be supported.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Low Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0152 Request parameter routineControlType with value 0x03 (requestRoutineResults) shall not be supported. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 67 · page 67 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0153 | 5.6.1.3 Positive responseTable 76 – RoutineControl (CheckProgrammingPreconditions) positive response format #1 RoutineControl Response SID M 0x71 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) checkProgrammingPreconditions [byte#1] M 0x22 #4 routineIdentifier (LSB) checkProgrammingPreconditions [byte#2] M 0x03 #5 routineStatus (byte#1) programmingPreconditionList [byte#1] U 0x00-0xFF #5+m-1 routineStatus (byte#m) programmingPreconditionList [byte#m] U 0x00-0xFF REQ_UDS 0154 Each routineStatus byte shall represent one not satisfied precondition according to Table 18 (see definition of “Satisfied programming precondition”).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Secure software update and flash readiness Architecture: System Core SSR: SSR-UPD-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 5.6.1.3 Positive response REQ_UDS 0153 Table 76 – RoutineControl (CheckProgrammingPreconditions) positive response format #1 RoutineControl Response SID M 0x71 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) checkProgrammingPreconditions [byte#1] M 0x22 #4 routineIdentifier (LSB) checkProgrammingPreconditions [byte#2] M 0x03 #5 routineStatus (byte#1) programmingPreconditionList [byte#1] U 0x00-0xFF #5+m-1 routineStatus (byte#m) programmingPreconditionList [byte#m] U 0x00-0xFF REQ_UDS 0154 Each routineStatus byte shall represent one not satisfied precondition according to Table 18 (see definition of “Satisfied programming precondition”). Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-UPD-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 67 · page 67 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0155 | Internal Page 68 (90)Which ones of the programming precondition codes in Table 18 that need to be supported shall be discussed and agreed with the vehicle manufacturer.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Secure software update and flash readiness / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-UPD-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text Internal Page 68 (90) REQ_UDS 0155 Which ones of the programming precondition codes in Table 18 that need to be supported shall be discussed and agreed with the vehicle manufacturer. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Secure software update and flash readiness | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-UPD-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 68 · page 68 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0156 | If all preconditions are satisfied, no routineStatus byte shall be reported.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0156 If all preconditions are satisfied, no routineStatus byte shall be reported. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 68 · page 68 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0157 | Programming preconditions that do not map to one of the entries in Table 77 shall be discussed with the vehicle manufacturer.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Secure software update and flash readiness / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-UPD-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0157 Programming preconditions that do not map to one of the entries in Table 77 shall be discussed with the vehicle manufacturer. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Secure software update and flash readiness | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-UPD-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 68 · page 68 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00702 | Table 77 – Programming preconditions Hex Description Origin 0x01 Engine speed is not zero Defined by the “manufacturers software initiative” (HIS) 0x02 Engine immobilizer is not released 0x03 Transmission input speed is not zero 0x04 Transmission output speed is not zero 0x05 Vehicle speed is not zero 0x06 Closed-loop control active 0x07 Ignition system off-on required 0x08 No programming voltage 0x09 Ignition (terminal 15) is not turned on 0x0A Supply voltage too low 0x0B Temperature too high 0x0C Temperature too low ..Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior; Secure software update and flash readiness Architecture: Application Software SSR: SSR-UPD-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text Table 77 – Programming preconditions Hex Description Origin 0x01 Engine speed is not zero Defined by the “manufacturers software initiative” (HIS) 0x02 Engine immobilizer is not released 0x03 Transmission input speed is not zero 0x04 Transmission output speed is not zero 0x05 Vehicle speed is not zero 0x06 Closed-loop control active 0x07 Ignition system off-on required 0x08 No programming voltage 0x09 Ignition (terminal 15) is not turned on 0x0A Supply voltage too low 0x0B Temperature too high 0x0C Temperature too low .. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-UPD-003 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 68 · page 68 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0158 | The server shall respond with a positive response code without erasing memory if the specified memory area has already been completely erased (or is writable) at the time the service is requested.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text REQ_UDS 0158 The server shall respond with a positive response code without erasing memory if the specified memory area has already been completely erased (or is writable) at the time the service is requested. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 69 · page 69 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00704 | INFO_UDS 0020 In order to satisfy stability requirements, the erasing of the boot loader may require that the current boot loader be copied into another non-volatile memory area before the boot loader memory is erased, see Annex A for an implementation hint.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | Low Proposal Ready Open point: - | DetailsFull requirement text INFO_UDS 0020 In order to satisfy stability requirements, the erasing of the boot loader may require that the current boot loader be copied into another non-volatile memory area before the boot loader memory is erased, see Annex A for an implementation hint. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Non-functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 69 · page 69 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0159 | In case the non volatile memory area is currently hosting a bootloader copy, meaning there is an ongoing bootloader update procedure, the ECU shall ensure that this memory area shall not be erased until a valid bootloader is flashed in the bootloader memory area.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Hardware platform support; Secure software update and flash readiness Architecture: Hardware Platform SSR: SSR-BOOT-002 | High Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0159 In case the non volatile memory area is currently hosting a bootloader copy, meaning there is an ongoing bootloader update procedure, the ECU shall ensure that this memory area shall not be erased until a valid bootloader is flashed in the bootloader memory area. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-BOOT-002 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 69 · page 69 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Medium, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0160 | Internal Page 70 (90)When the addressAndLengthFormatIdentifier parameter is set to a value > 0x00 the server shall reset the following software and data identification DIDs to their default values (see section Software and data identification): • If boot software (any part) is erased, reset 0xF180, 0xF191 and 0xF187 to default values (some of the DIDs will be automatically erased as a consequence of erasing one or more modules).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text Internal Page 70 (90) REQ_UDS 0160 When the addressAndLengthFormatIdentifier parameter is set to a value > 0x00 the server shall reset the following software and data identification DIDs to their default values (see section Software and data identification): • If boot software (any part) is erased, reset 0xF180, 0xF191 and 0xF187 to default values (some of the DIDs will be automatically erased as a consequence of erasing one or more modules). Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 70 · page 70 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0161 | The erasing of memory shall not prevent the client from starting a data transfer using the TransferData (0x36) service, i.e.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SDT-001 | Low Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0161 The erasing of memory shall not prevent the client from starting a data transfer using the TransferData (0x36) service, i.e. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SDT-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 70 · page 70 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00708 | the erasing of memory shall proceed in parallel with data transfer in case for ECUs implementing Automatic erase.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Hardware platform support Architecture: Hardware Platform SSR: SSR-HW-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text the erasing of memory shall proceed in parallel with data transfer in case for ECUs implementing Automatic erase. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-HW-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 70 · page 70 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ_UDS-0162 | This routine shall be supported in Programming session.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Secure software update and flash readiness Architecture: System Core SSR: SSR-UPD-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0162 This routine shall be supported in Programming session. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-UPD-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 70 · page 70 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0163 | 5.6.2.1 RequestTable 78 – RoutineIdentifier 0xFF00 description #1 RoutineControl Request SID M 0x31 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) M 0xFF #4 routineIdentifier (LSB) M 0x00 #5 addressAndLengthFormatIdentifier (XXXXYYYYb) XXXXb = number of bytes of memorySize parameter YYYYb = number of bytes of memoryStartAddress parameter.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.6.2.1 Request REQ_UDS 0163 Table 78 – RoutineIdentifier 0xFF00 description #1 RoutineControl Request SID M 0x31 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) M 0xFF #4 routineIdentifier (LSB) M 0x00 #5 addressAndLengthFormatIdentifier (XXXXYYYYb) XXXXb = number of bytes of memorySize parameter YYYYb = number of bytes of memoryStartAddress parameter. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 70 · page 70 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0164 | Internal Page 71 (90)Request parameter routineControlType with value 0x03 (requestRoutineResults) shall not be supported 5.6.2.2 Request parameter addressAndLengthFormatIdentifier REQ_UDS 0165 Table 79 – Request parameter addressAndLengthFormatIdentifier values Byte Value Description Cvt 0x00 Automatic erase: Erase is performed by boot loader automatically when RequestDownload is received for each Flash sector in the module.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Secure software update and flash readiness Architecture: System Core SSR: SSR-BOOT-003 | High Proposal Ready Open point: - | DetailsFull requirement text Internal Page 71 (90) REQ_UDS 0164 Request parameter routineControlType with value 0x03 (requestRoutineResults) shall not be supported 5.6.2.2 Request parameter addressAndLengthFormatIdentifier REQ_UDS 0165 Table 79 – Request parameter addressAndLengthFormatIdentifier values Byte Value Description Cvt 0x00 Automatic erase: Erase is performed by boot loader automatically when RequestDownload is received for each Flash sector in the module. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-BOOT-003 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 71 · page 71 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Medium, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00712 | 02, Module 2 (Application SW module) M 0x02 – 0xFF Physical memory range erase: Refer to ISO 14229-1 Table H1 M C = Mandatory if required to meet the performance requirements & SUV2_REQ 62 & SUV2_REQ 63 in CVS123.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-008 | Medium Proposal Ready Open point: - | DetailsFull requirement text 02, Module 2 (Application SW module) M 0x02 – 0xFF Physical memory range erase: Refer to ISO 14229-1 Table H1 M C = Mandatory if required to meet the performance requirements & SUV2_REQ 62 & SUV2_REQ 63 in CVS123. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-008 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 71 · page 71 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ_UDS-0166 | When the addressAndLengthFormatIdentifier is set to 0x01 the following defined module to index mapping shall apply for the memoryStartAddress: 1 – Boot loader 2 – Application 3 – Application Data 4 ...Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-BOOT-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0166 When the addressAndLengthFormatIdentifier is set to 0x01 the following defined module to index mapping shall apply for the memoryStartAddress: 1 – Boot loader 2 – Application 3 – Application Data 4 ... Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-BOOT-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 71 · page 71 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0167 | 255 – System specific 5.6.2.3 Positive responseTable 80 – RoutineControl (EraseMemory) positive response format #1 RoutineControl Response SID M 0x71 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) eraseMemory [byte#1] M 0xFF #4 routineIdentifier (LSB) eraseMemory [byte#2] M 0x00 #5 routineStatus routineResult M 0x00-0xFFExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 255 – System specific 5.6.2.3 Positive response REQ_UDS 0167 Table 80 – RoutineControl (EraseMemory) positive response format #1 RoutineControl Response SID M 0x71 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) eraseMemory [byte#1] M 0xFF #4 routineIdentifier (LSB) eraseMemory [byte#2] M 0x00 #5 routineStatus routineResult M 0x00-0xFF Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 71 · page 71 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0168 | Internal Page 72 (90)The routineResult byte values shall be as specified in Table 81.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text Internal Page 72 (90) REQ_UDS 0168 The routineResult byte values shall be as specified in Table 81. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 72 · page 72 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0169 | Internal Page 74 (90) #2 routineControlType (StartRoutine) 0x01 #3 routineIdentifier (MSB) 0xFF #4 routineIdentifier (LSB) 0x00 Example #2: Negative response: server → client Table 87 – Example #2: Negative response: server → client #1 Negative Response 0x7F #2 RoutineControl Response SID 0x31 #3 conditionsNotCorrect 0x22 5.6.3 Routine 0x2401 – Software Installation The RoutineIdentifier may verify the authenticity of the received file package.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | Low Proposal Ready Open point: - | DetailsFull requirement text Internal Page 74 (90) #2 routineControlType (StartRoutine) 0x01 #3 routineIdentifier (MSB) 0xFF #4 routineIdentifier (LSB) 0x00 Example #2: Negative response: server → client Table 87 – Example #2: Negative response: server → client #1 Negative Response 0x7F #2 RoutineControl Response SID 0x31 #3 conditionsNotCorrect 0x22 5.6.3 Routine 0x2401 – Software Installation REQ_UDS 0169 The RoutineIdentifier may verify the authenticity of the received file package. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 74 · page 74 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT High, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0170 | If authenticity verification is valid the server shall initiate all necessary steps for installation of the received file.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration; Security evidence and traceability / OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface SSR: SSR-DAI-004 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text REQ_UDS 0170 If authenticity verification is valid the server shall initiate all necessary steps for installation of the received file. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Backend and IT integration; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Backend and IT Systems; OEM/Customer Review Interface | Work product: Requirement traceability record | SSR: SSR-DAI-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 74 · page 74 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0171 | The server shall send a response to RoutineIdentifier 0x2401 Software Installation without any further inputs from the client.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text REQ_UDS 0171 The server shall send a response to RoutineIdentifier 0x2401 Software Installation without any further inputs from the client. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 74 · page 74 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0172 | If authenticity verification fails the server shall send the positive response with AuthenticityVerificationStatus bit 7-6 (AuthenticityStatus) set to 0x02 (Authenticity Verification Failed) and SoftwareInstallationStatus bit 7-6 (InstallationStatus) set to 0x02 (Installation Failed).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration; Security evidence and traceability / OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface SSR: SSR-DAI-004 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text REQ_UDS 0172 If authenticity verification fails the server shall send the positive response with AuthenticityVerificationStatus bit 7-6 (AuthenticityStatus) set to 0x02 (Authenticity Verification Failed) and SoftwareInstallationStatus bit 7-6 (InstallationStatus) set to 0x02 (Installation Failed). Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Backend and IT integration; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Backend and IT Systems; OEM/Customer Review Interface | Work product: Requirement traceability record | SSR: SSR-DAI-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 74 · page 74 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0173 | This routine shall be supported in Programming session.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Secure software update and flash readiness Architecture: System Core SSR: SSR-UPD-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0173 This routine shall be supported in Programming session. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-UPD-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 74 · page 74 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0174 | 5.6.3.1 RequestRequest parameter RoutineControlOptionRecord shall not be supported.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Low Proposal Ready Open point: - | DetailsFull requirement text 5.6.3.1 Request REQ_UDS 0174 Request parameter RoutineControlOptionRecord shall not be supported. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 74 · page 74 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0175 | Internal Page 75 (90) 5.6.3.2 Positive ResponsePositive responses to RoutineControl (Software Installation) service requests shall be formatted according to Table 88 and Table 89.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text Internal Page 75 (90) 5.6.3.2 Positive Response REQ_UDS 0175 Positive responses to RoutineControl (Software Installation) service requests shall be formatted according to Table 88 and Table 89. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 75 · page 75 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0176 | Description Cvt Values #1 RoutineControl Request SID M 0x71 #2 routineControlType (requestRoutineResults) M 0x03 #3 routineIdentifier (MSB) M 0x24 #4 routineIdentifier (LSB) M 0x01 #5 AuthenticityVerificationStatus M 0x00 – 0xFF #6 SoftwareInstallationStatus M 0x00 – 0xFF #7 CompletionPercentage M 0x00 – 0x64 #8-#9 TimeRemaningEstimative M 0x0000 – 0xFFFF AuthenticityVerificationStatus shall be formatted according to Table 90.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Security evidence and traceability / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-DAI-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text Description Cvt Values #1 RoutineControl Request SID M 0x71 #2 routineControlType (requestRoutineResults) M 0x03 #3 routineIdentifier (MSB) M 0x24 #4 routineIdentifier (LSB) M 0x01 #5 AuthenticityVerificationStatus M 0x00 – 0xFF #6 SoftwareInstallationStatus M 0x00 – 0xFF #7 CompletionPercentage M 0x00 – 0x64 #8-#9 TimeRemaningEstimative M 0x0000 – 0xFFFF REQ_UDS 0176 AuthenticityVerificationStatus shall be formatted according to Table 90. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-DAI-002 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 75 · page 75 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0177 | AuthenticityVerificationStatus bit 7-6 (AuthenticityStatus) shall remain as 0x0 (Software Authenticity Invalid) until the verification completes.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior; Security evidence and traceability / OEM/Customer Review Interface Architecture: Application Software; OEM/Customer Review Interface SSR: SSR-DAI-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0177 AuthenticityVerificationStatus bit 7-6 (AuthenticityStatus) shall remain as 0x0 (Software Authenticity Invalid) until the verification completes. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Application Software; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-DAI-003 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 75 · page 75 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0178 | If no authenticity verification will take place as part of RoutineIdentifier, the AuthenticityVerificationStatus bit 7-6 (AuthenticityStatus) shall be changed to 0x1 (Authenticity Verification Successful).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Security evidence and traceability / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-DAI-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0178 If no authenticity verification will take place as part of RoutineIdentifier, the AuthenticityVerificationStatus bit 7-6 (AuthenticityStatus) shall be changed to 0x1 (Authenticity Verification Successful). Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-DAI-002 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 75 · page 75 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0179 | Internal Page 76 (90) 0x1: Authenticity Verification Successful 0x2: Authenticity Verification Failed 5-0 Reserved Note: Shall be kept as 0x0 SoftwareInstallationStatus shall be formatted according to Table 91.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Security evidence and traceability / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-DAI-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text Internal Page 76 (90) 0x1: Authenticity Verification Successful 0x2: Authenticity Verification Failed 5-0 Reserved Note: Shall be kept as 0x0 REQ_UDS 0179 SoftwareInstallationStatus shall be formatted according to Table 91. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-DAI-002 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 76 · page 76 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0180 | SoftwareInstallationStatus bit 7-6 (InstallationStatus) shall remain as 0x0 (Installation On-going) until the installation completes.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0180 SoftwareInstallationStatus bit 7-6 (InstallationStatus) shall remain as 0x0 (Installation On-going) until the installation completes. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 76 · page 76 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0181 | Table 91 – SoftwareInstallationStatus Bit Bit Name Bit Values Description 7-6 InstallationStatus 0x0: Installation On-going 0x1: Installation Successful 0x2: Installation Failed 5 - 3 InstallationFailureType 0x0: No Failures 0x1 – 0x7: Project Specific 2 ResetRequired 0x0: Reset not required 0x1: Reset required 1 - 0 Reserved Note: Shall be kept as 0x0 CompletionPercentage shall inform the progress percentage of the software has been installed in the partition memory area.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text Table 91 – SoftwareInstallationStatus Bit Bit Name Bit Values Description 7-6 InstallationStatus 0x0: Installation On-going 0x1: Installation Successful 0x2: Installation Failed 5 - 3 InstallationFailureType 0x0: No Failures 0x1 – 0x7: Project Specific 2 ResetRequired 0x0: Reset not required 0x1: Reset required 1 - 0 Reserved Note: Shall be kept as 0x0 REQ_UDS 0181 CompletionPercentage shall inform the progress percentage of the software has been installed in the partition memory area. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 76 · page 76 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00729 | Information shall be provided in percentage.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text Information shall be provided in percentage. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 76 · page 76 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ_UDS-0182 | TimeRemaningEstimative shall inform the time estimative to complete the installation of the file.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0182 TimeRemaningEstimative shall inform the time estimative to complete the installation of the file. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 76 · page 76 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00731 | Information shall be provided in seconds.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text Information shall be provided in seconds. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 76 · page 76 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00732 | 5.6.3.3 Negative response INFO_UDS 0028 Whereas the result of the dependency check is returned as part of a positive response, a negative response code (NRC) shall be returned if the normal conditions according to (ISO 14229-1) (authentication, service request length, parameter range check etc) for performing the service are not correct.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | High Proposal Ready Open point: - | DetailsFull requirement text 5.6.3.3 Negative response INFO_UDS 0028 Whereas the result of the dependency check is returned as part of a positive response, a negative response code (NRC) shall be returned if the normal conditions according to (ISO 14229-1) (authentication, service request length, parameter range check etc) for performing the service are not correct. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 76 · page 76 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00733 | 5.6.4 Routine 0xFF01 – CheckProgrammingDependencies (check the flash programming) INFO_UDS 0029 This RoutineIdentifier value allows the client to start a consistency check of the server and should be able to execute independent from programming sequence.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration; Secure software update and flash readiness Architecture: Backend and IT Systems SSR: SSR-UPD-005 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text 5.6.4 Routine 0xFF01 – CheckProgrammingDependencies (check the flash programming) INFO_UDS 0029 This RoutineIdentifier value allows the client to start a consistency check of the server and should be able to execute independent from programming sequence. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Backend and IT integration; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-UPD-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 76 · page 76 Estimation / resource / tool / IT / hardware impact Effort High, Competence Low, Tooling Medium, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0183 | Internal Page 77 (90)The server shall check whether or not the individual modules are complete and compatible with one another.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-DIAG-003 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text Internal Page 77 (90) REQ_UDS 0183 The server shall check whether or not the individual modules are complete and compatible with one another. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-DIAG-003 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 77 · page 77 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00735 | In addition, a check shall be made to determine whether or not the software is compatible with the hardware version (e.g., variants of sensors/actuators) and other data structures (e.g., EEPROM data).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-008 | Medium Proposal Ready Open point: - | DetailsFull requirement text In addition, a check shall be made to determine whether or not the software is compatible with the hardware version (e.g., variants of sensors/actuators) and other data structures (e.g., EEPROM data). Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-008 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 77 · page 77 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ_UDS-0184 | The method used to check compatibility/consistency shall be determined by the supplier in consultation with the vehicle manufacturer.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-DIAG-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0184 The method used to check compatibility/consistency shall be determined by the supplier in consultation with the vehicle manufacturer. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 77 · page 77 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0185 | The consistency check shall be carried out solely by the server.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-DIAG-003 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text REQ_UDS 0185 The consistency check shall be carried out solely by the server. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-DIAG-003 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 77 · page 77 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0186 | The server shall verify the authenticity and integrity of the software as a part of the consistency check.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DAI-003 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text REQ_UDS 0186 The server shall verify the authenticity and integrity of the software as a part of the consistency check. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DAI-003 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 77 · page 77 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0187 | The authenticity and integrity information shall be supplied to the server before the software is updated.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DAI-003 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text REQ_UDS 0187 The authenticity and integrity information shall be supplied to the server before the software is updated. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DAI-003 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 77 · page 77 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0188 | The authenticity and integrity check shall be carried out solely by the server.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-DAI-004 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text REQ_UDS 0188 The authenticity and integrity check shall be carried out solely by the server. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-DAI-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 77 · page 77 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0189 | This routine shall be supported in Programming session.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Secure software update and flash readiness Architecture: System Core SSR: SSR-UPD-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0189 This routine shall be supported in Programming session. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-UPD-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 77 · page 77 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0190 | 5.6.4.1 RequestThe server shall support RoutineControl (CheckProgrammingDependencies) service request formatted according to Table 92.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior; Secure software update and flash readiness Architecture: Application Software SSR: SSR-UPD-003 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text 5.6.4.1 Request REQ_UDS 0190 The server shall support RoutineControl (CheckProgrammingDependencies) service request formatted according to Table 92. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Application software behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-UPD-003 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 77 · page 77 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0191 | Table 92 – RoutineIdentifier 0xFF01 description Byte Description Cvt Hex #1 RoutineControl Request SID M 0x31 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) M 0xFF #4 routineIdentifier (LSB) M 0x01 Request parameter routineControlType with value 0x03 (requestRoutineResults) shall not be supported.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Low Proposal Ready Open point: - | DetailsFull requirement text Table 92 – RoutineIdentifier 0xFF01 description Byte Description Cvt Hex #1 RoutineControl Request SID M 0x31 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) M 0xFF #4 routineIdentifier (LSB) M 0x01 REQ_UDS 0191 Request parameter routineControlType with value 0x03 (requestRoutineResults) shall not be supported. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 77 · page 77 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0192 | Internal Page 78 (90) 5.6.4.2 Positive responsePositive responses to RoutineControl (CheckProgrammingDependencies) service requests shall be formatted according to Table 93.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior; Secure software update and flash readiness Architecture: Application Software SSR: SSR-UPD-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text Internal Page 78 (90) 5.6.4.2 Positive response REQ_UDS 0192 Positive responses to RoutineControl (CheckProgrammingDependencies) service requests shall be formatted according to Table 93. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-UPD-003 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 78 · page 78 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0193 | Table 93 – RoutineControl (CheckProgrammingDependencies) positive response format #1 RoutineControl Response SID M 0x71 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) checkProgrammingDependencies[byte#1] M 0xFF #4 routineIdentifier (LSB) checkProgrammingDependencies [byte#2] M 0x01 #5 routineStatus routineResult M 0x00-0xFF Parameter routineResult shall adopt one of the values specified in Table 94.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Secure software update and flash readiness Architecture: System Core SSR: SSR-UPD-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text Table 93 – RoutineControl (CheckProgrammingDependencies) positive response format #1 RoutineControl Response SID M 0x71 #2 routineControlType (StartRoutine) M 0x01 #3 routineIdentifier (MSB) checkProgrammingDependencies[byte#1] M 0xFF #4 routineIdentifier (LSB) checkProgrammingDependencies [byte#2] M 0x01 #5 routineStatus routineResult M 0x00-0xFF REQ_UDS 0193 Parameter routineResult shall adopt one of the values specified in Table 94. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-UPD-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 78 · page 78 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00746 | Table 94 – CheckProgrammingDependencies routineStatusRecord results 0x00 correctResult M 0x01 incorrectResult M 0x02 incorrectResult error SW – HW M 0x03 incorrectResult error SW – SW M 0x04 IncorrectResult One or more modules are not programmed or are incorrectly programmed M 0x05 incorrectResult One or more modules failed when verifying the authenticity and integrity of the software M 0x06 – 0xFF Reserved 5.6.4.3 Negative response INFO_UDS 0030 Whereas the result of the dependency check is returned as part of a positive response, a negative response code (NRC) shall be returned if the normal conditions according to (ISO 14229-1)(authentication, service request length, parameter range check etc) for performing the service are not correct.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement ECU-side secure update/bootloader behavior, including controlled programming state, authenticity/integrity checks, and verification evidence, subject to customer-confirmed SUV2 applicability and update-chain ownership.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior; Secure software update and flash readiness Architecture: Application Software SSR: SSR-UPD-003 | High Proposal Ready Open point: - | DetailsFull requirement text Table 94 – CheckProgrammingDependencies routineStatusRecord results 0x00 correctResult M 0x01 incorrectResult M 0x02 incorrectResult error SW – HW M 0x03 incorrectResult error SW – SW M 0x04 IncorrectResult One or more modules are not programmed or are incorrectly programmed M 0x05 incorrectResult One or more modules failed when verifying the authenticity and integrity of the software M 0x06 – 0xFF Reserved 5.6.4.3 Negative response INFO_UDS 0030 Whereas the result of the dependency check is returned as part of a positive response, a negative response code (NRC) shall be returned if the normal conditions according to (ISO 14229-1)(authentication, service request length, parameter range check etc) for performing the service are not correct. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-UPD-003 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 78 · page 78 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0194 | Table 96 – Positive response: server → client #1 RoutineControl Response SID 0x71 #2 routineControlType (StartRoutine) 0x01 #3 routineIdentifier byte#1 (checkProgrammingDependencies MSB) 0xFF #4 routineIdentifier byte#2 (checkProgrammingDependencies LSB) 0x01 #5 routineStatus (routineResult) 0x00 5.6.5 Routine 0xCAFE – EMP The request and response shall be implemented according to CVS33.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. ECU-side bootloader/update behavior can be implemented after the customer confirms the applicable SUV2 variant, diagnostic programming sequence, security-access expectations, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration; Secure software update and flash readiness Architecture: Backend and IT Systems SSR: SSR-UPD-005 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text Table 96 – Positive response: server → client #1 RoutineControl Response SID 0x71 #2 routineControlType (StartRoutine) 0x01 #3 routineIdentifier byte#1 (checkProgrammingDependencies MSB) 0xFF #4 routineIdentifier byte#2 (checkProgrammingDependencies LSB) 0x01 #5 routineStatus (routineResult) 0x00 5.6.5 Routine 0xCAFE – EMP REQ_UDS 0194 The request and response shall be implemented according to CVS33. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Backend and IT integration; Secure software update and flash readiness | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-UPD-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 79 · page 79 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0195 | This routine shall be supported in all sessions of Application and Boot.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0195 This routine shall be supported in all sessions of Application and Boot. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 79 · page 79 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0196 | Internal Page 80 (90) 5.7 Fault memory requirements 5.7.1 DTC status bitsTable 97 – Fault memory DTC status bits description Bit Description Cvt 0 testFailed M 1 testFailedThisOperationCycle U 2 pendingDTC M 3 confirmedDTC M 4 testNotCompletedSinceLastClear E 5 testFailedSinceLastClear U 6 testNotCompletedThisOperationCycle M 7 warningIndicatorRequested M REQ_UDS 0197 DTC status bits shall not make use of any vehicle manufacturer specific reset condition (e.g.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Hardware platform support / OEM/Customer Review Interface Architecture: Hardware Platform; OEM/Customer Review Interface SSR: SSR-DIAG-006 | Low Proposal Ready Open point: - | DetailsFull requirement text Internal Page 80 (90) 5.7 Fault memory requirements 5.7.1 DTC status bits REQ_UDS 0196 Table 97 – Fault memory DTC status bits description Bit Description Cvt 0 testFailed M 1 testFailedThisOperationCycle U 2 pendingDTC M 3 confirmedDTC M 4 testNotCompletedSinceLastClear E 5 testFailedSinceLastClear U 6 testNotCompletedThisOperationCycle M 7 warningIndicatorRequested M REQ_UDS 0197 DTC status bits shall not make use of any vehicle manufacturer specific reset condition (e.g. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Hardware platform support | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Hardware Platform; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-DIAG-006 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 80 · page 80 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Medium, IT Low, HW/Test High Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0198 | The occurrence counter minimum value shall be zero (0).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0198 The occurrence counter minimum value shall be zero (0). Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 80 · page 80 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0199 | The occurrence counter maximum value shall be 126.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0199 The occurrence counter maximum value shall be 126. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 80 · page 80 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0200 | The occurrence counter default value shall be zero (0).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0200 The occurrence counter default value shall be zero (0). Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 80 · page 80 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0201 | The occurrence counter shall increment by one (1) only.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Low Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0201 The occurrence counter shall increment by one (1) only. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 80 · page 80 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0202 | The occurrence counter shall increment if it’s value is not at it’s maximum value already.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-DIAG-003 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text REQ_UDS 0202 The occurrence counter shall increment if it’s value is not at it’s maximum value already. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-DIAG-003 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 80 · page 80 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0203 | The occurrence counter shall increment at a change of DTC status bits 0 testFailed and 3 confirmedDTC both from 0 to 1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0203 The occurrence counter shall increment at a change of DTC status bits 0 testFailed and 3 confirmedDTC both from 0 to 1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 80 · page 80 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0204 | Internal Page 81 (90)The occurrence counter shall increment at a change of DTC status bit 0 testFailed from 0 to 1, if bit 3 confirmedDTC is 1 already.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text Internal Page 81 (90) REQ_UDS 0204 The occurrence counter shall increment at a change of DTC status bit 0 testFailed from 0 to 1, if bit 3 confirmedDTC is 1 already. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 81 · page 81 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0205 | The occurrence counter shall increment at a change of DTC status bit 3 confirmedDTC from 0 to 1, if bit 0 testFailed is 1 already.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0205 The occurrence counter shall increment at a change of DTC status bit 3 confirmedDTC from 0 to 1, if bit 0 testFailed is 1 already. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 81 · page 81 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0206 | The occurrence counter value 127 shall be defined as "errors with the counter".Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0206 The occurrence counter value 127 shall be defined as "errors with the counter". Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 81 · page 81 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0207 | The timestamp default value shall be a 0xFF in each data.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0207 The timestamp default value shall be a 0xFF in each data. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 81 · page 81 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0208 | The timestamp is presented in SAE J1939-71 format without local hour/minute offsets.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0208 The timestamp is presented in SAE J1939-71 format without local hour/minute offsets. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 81 · page 81 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0209 | In SAE J1939-71 section “PGN 65254 Time/Date”, the following format is specified: Table 98 – J1939-71 timestamp format Byte No Length Name Resolutio n Offset Note 1 1 byte Seconds 0.25 s/bit 0 2 1 byte Minutes 1 min/bit 0 3 1 byte Hours 1 hr/bit 0 4 1 byte Month 1 month/bit 0 Value 1 identifies January, value 2 identifies February and so on 5 1 byte Day 0.25 days/bit 0 Values 1,2,3 and 4 identifes first day of month, value 5,6,7,8 identifies second day of month and so on 6 1 byte Year 1 year/bit 1985 Value of 0 identifies year 1985, value of 1 identifes year 1986 and so on 7 1 byte Local minute offset 1 min/bit -125 Not used in DTC timestamps 8 1 byte Local hour offset 1 hr/bit -125 Not used in DTC timestampsExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0209 In SAE J1939-71 section “PGN 65254 Time/Date”, the following format is specified: Table 98 – J1939-71 timestamp format Byte No Length Name Resolutio n Offset Note 1 1 byte Seconds 0.25 s/bit 0 2 1 byte Minutes 1 min/bit 0 3 1 byte Hours 1 hr/bit 0 4 1 byte Month 1 month/bit 0 Value 1 identifies January, value 2 identifies February and so on 5 1 byte Day 0.25 days/bit 0 Values 1,2,3 and 4 identifes first day of month, value 5,6,7,8 identifies second day of month and so on 6 1 byte Year 1 year/bit 1985 Value of 0 identifies year 1985, value of 1 identifes year 1986 and so on 7 1 byte Local minute offset 1 min/bit -125 Not used in DTC timestamps 8 1 byte Local hour offset 1 hr/bit -125 Not used in DTC timestamps Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 81 · page 81 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0210 | Internal Page 82 (90) 5.7.3.1 Latest occurrenceThe latest occurrence shall be updated at a change of DTC status bits 0 (testFailed) and 3 The latest occurrence shall be updated at a change of DTC status bit 0 (testFailed) from 0 to 1, if bit 3 (confirmedDTC) is 1 already.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | High Proposal Ready Open point: - | DetailsFull requirement text Internal Page 82 (90) 5.7.3.1 Latest occurrence REQ_UDS 0210 The latest occurrence shall be updated at a change of DTC status bits 0 (testFailed) and 3 REQ_UDS 0210 The latest occurrence shall be updated at a change of DTC status bit 0 (testFailed) from 0 to 1, if bit 3 (confirmedDTC) is 1 already. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 82 · page 82 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0211 | If occurrence counter is set to 1, the timestamp of the latest occurrence shall be set to 0xFF.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0211 If occurrence counter is set to 1, the timestamp of the latest occurrence shall be set to 0xFF. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 82 · page 82 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0212 | 5.7.3.2 First occurrenceThe first occurrence shall be updated at the first change of DTC status bits 0 (testFailed) and 3 5.7.4 Vehicle distance at occurrence INFO_UDS 0036 The total vehicle distance at occurrence is used in DTCExtDataRecords, see section 5.5.10.2.8.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text 5.7.3.2 First occurrence REQ_UDS 0212 The first occurrence shall be updated at the first change of DTC status bits 0 (testFailed) and 3 5.7.4 Vehicle distance at occurrence INFO_UDS 0036 The total vehicle distance at occurrence is used in DTCExtDataRecords, see section 5.5.10.2.8. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 82 · page 82 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Medium, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0213 | The vehicle distance shall be represented by a four byte integer, big endian, with five meter per bit (5m/bit).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0213 The vehicle distance shall be represented by a four byte integer, big endian, with five meter per bit (5m/bit). Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 82 · page 82 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0214 | If all sources of vehicle distance information present no current data, the distance information shall be set to 0xFF at all bytes.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0214 If all sources of vehicle distance information present no current data, the distance information shall be set to 0xFF at all bytes. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 82 · page 82 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0215 | 5.7.4.1 Latest occurrenceThe latest distance value is updated at a change of DTC status bits 0 (testFailed) and 3 REQ_UDS 0216 The latest distance value is updated at a change of DTC status bit 0 (testFailed) from 0 to 1, if bit 3 (confirmedDTC) is 1 already.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.7.4.1 Latest occurrence REQ_UDS 0215 The latest distance value is updated at a change of DTC status bits 0 (testFailed) and 3 REQ_UDS 0216 The latest distance value is updated at a change of DTC status bit 0 (testFailed) from 0 to 1, if bit 3 (confirmedDTC) is 1 already. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 82 · page 82 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0217 | 5.7.4.2 First occurrenceThe first distance value is updated at the first change of DTC status bits 0 (testFailed) and 3Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.7.4.2 First occurrence REQ_UDS 0217 The first distance value is updated at the first change of DTC status bits 0 (testFailed) and 3 Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 82 · page 82 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0218 | The operational hours are presented by a four byte integer, big endian, with , half second per bit (0,5s/bit).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0218 The operational hours are presented by a four byte integer, big endian, with , half second per bit (0,5s/bit). Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 83 · page 83 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0219 | If all sources of operational hours information present no current data, the operational hours information shall be set to 0xFF at all bytes.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0219 If all sources of operational hours information present no current data, the operational hours information shall be set to 0xFF at all bytes. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 83 · page 83 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0220 | 5.7.5.1 Latest occurrenceThe latest operational hours value is updated at a change of DTC status bits 0 (testFailed) and 3 (confirmedDTC) both from 0 to 1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.7.5.1 Latest occurrence REQ_UDS 0220 The latest operational hours value is updated at a change of DTC status bits 0 (testFailed) and 3 (confirmedDTC) both from 0 to 1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 83 · page 83 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0221 | The latest operational hours value is updated at a change of DTC status bit 0 (testFailed) from 0 to 1, if bit 3 (confirmedDTC) is 1 already.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0221 The latest operational hours value is updated at a change of DTC status bit 0 (testFailed) from 0 to 1, if bit 3 (confirmedDTC) is 1 already. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 83 · page 83 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0222 | 5.7.5.2 First occurrenceThe first operational hours value is updated at the first change of DTC status bits 0 (testFailed) and 3 (confirmedDTC) both from 0 to 1.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text 5.7.5.2 First occurrence REQ_UDS 0222 The first operational hours value is updated at the first change of DTC status bits 0 (testFailed) and 3 (confirmedDTC) both from 0 to 1. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 83 · page 83 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0223 | 5.9 Performance requirements on CANThe server shall be available for complete diagnostic communication within two seconds after a power on.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Diagnostic security | Feature / interface: Diagnostic security Architecture: Security Services SSR: SSR-RBAC-001 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text 5.9 Performance requirements on CAN REQ_UDS 0223 The server shall be available for complete diagnostic communication within two seconds after a power on. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Diagnostic security | Security capability: Diagnostic security | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 83 · page 83 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0224 | If diagnostic data is not available in time the ECU should respond with NRC 0x78 (requestCorrectlyReceived-ResponsePending) for maximum allowed time.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Validate assumption with customer; complete mapping; implement. | Diagnostic security | Feature / interface: Diagnostic security Architecture: Security Services SSR: SSR-RBAC-001 | High Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0224 If diagnostic data is not available in time the ECU should respond with NRC 0x78 (requestCorrectlyReceived-ResponsePending) for maximum allowed time. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Diagnostic security | Security capability: Diagnostic security | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 83 · page 83 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00776 | for Linux based systems still running in boot, the server should indicate with DID 0xF1AD that it is running in boot.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-003 | Low Proposal Ready Open point: - | DetailsFull requirement text for Linux based systems still running in boot, the server should indicate with DID 0xF1AD that it is running in boot. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-003 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 83 · page 83 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0225 | 5.10 Session layer performance requirementsFor P2Server, the minimum value shall be 0 ms, a maximum value shall be 50 ms.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text 5.10 Session layer performance requirements REQ_UDS 0225 For P2Server, the minimum value shall be 0 ms, a maximum value shall be 50 ms. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 83 · page 83 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0226 | For P2Client, a value of 150 ms shall be used.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0226 For P2Client, a value of 150 ms shall be used. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 83 · page 83 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0227 | Internal Page 84 (90)For P2*Server, the minimum value shall be 0ms, the maximum value shall be 4000ms.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-DIAG-003 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text Internal Page 84 (90) REQ_UDS 0227 For P2*Server, the minimum value shall be 0ms, the maximum value shall be 4000ms. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-DIAG-003 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 84 · page 84 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0228 | For P2*Client, the value estimation given in ISO 14229-2 shall be used.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-DIAG-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_UDS 0228 For P2*Client, the value estimation given in ISO 14229-2 shall be used. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-DIAG-005 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 84 · page 84 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ_UDS-0229 | The value for P4_Server_max shall be maximum 30 seconds.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DIAG-001 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text REQ_UDS 0229 The value for P4_Server_max shall be maximum 30 seconds. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DIAG-001 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 84 · page 84 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0230 | The system supplier shall document the implemented value for P4_Server_max.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-DIAG-002 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text REQ_UDS 0230 The system supplier shall document the implemented value for P4_Server_max. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-DIAG-002 Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 84 · page 84 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_UDS-0339 | Internal Page 90 (90) Annex C (informative) Change history Release date Changes 2025-12 New requirements and infos: INFO_UDS 0039: F197 structure added F198 Request and response format REQ_UDS 0340: F199 Request and response format REQ_UDS 0341: F19A Request and response format REQ_UDS 0342: NRC for RBACC check failures REQ_UDS 0343, REQ_UDS 0344, REQ_UDS 0345, REQ_UDS 0346, REQ_UDS 0347, REQ_UDS 0348, REQ_UDS 0349: Requirements, Request and response formats for the ControlDTCSetting(0x85) added.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: Secure communication and freshness protection Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text Internal Page 90 (90) Annex C (informative) Change history Release date Changes 2025-12 New requirements and infos: INFO_UDS 0039: F197 structure added REQ_UDS 0339: F198 Request and response format REQ_UDS 0340: F199 Request and response format REQ_UDS 0341: F19A Request and response format REQ_UDS 0342: NRC for RBACC check failures REQ_UDS 0343, REQ_UDS 0344, REQ_UDS 0345, REQ_UDS 0346, REQ_UDS 0347, REQ_UDS 0348, REQ_UDS 0349: Requirements, Request and response formats for the ControlDTCSetting(0x85) added. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Secure communication and freshness protection | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 90 · page 90 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ_UDS-0003 | Modified requirementsAdded semantic Identifier DIDs, changed the NodeUID DID to INTERNAL REQ_UDS 0034: Change in the length of NodeUID(0xF1AF) INFO_UDS 0040: Change in the retrieval method for NodeUID(0xF1AF) REQ_UDS 0036: 0xF1B9 RBACCIdentifierNumber is changed to Mandatory REQ_UDS 0037: 0xF1BA RBACCStructureVersion,bit-length changed REQ_UDS 0045: Changes for service (0x84) and (0x31) REQ_UDS 0048: Updated the document references REQ_UDS 0107: 0XCAFE and 0xFF02 are updated to Mandatory REQ_UDS 0180: Modifcations on the bit values and new bit added REQ_UDS 0193: 0x05 is changed to Mandatory 6 Normative references: Updated the referenced documents and versions Removed Requirements and infos: REQ_UDS 0045: (0x86) service removed REQ_UDS 0053, REQ_UDS 0054: Removed the reserved DID ranges and 0xF1C1 REQ_UDS 0024: 0xF19E ODXFileDataIdentifier is removed 2024-10 First issueExpectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: Secure communication and freshness protection Architecture: None SSR: None | None Proposal Ready Open point: - | DetailsFull requirement text Modified requirements: REQ_UDS 0003: Added semantic Identifier DIDs, changed the NodeUID DID to INTERNAL REQ_UDS 0034: Change in the length of NodeUID(0xF1AF) INFO_UDS 0040: Change in the retrieval method for NodeUID(0xF1AF) REQ_UDS 0036: 0xF1B9 RBACCIdentifierNumber is changed to Mandatory REQ_UDS 0037: 0xF1BA RBACCStructureVersion,bit-length changed REQ_UDS 0045: Changes for service (0x84) and (0x31) REQ_UDS 0048: Updated the document references REQ_UDS 0107: 0XCAFE and 0xFF02 are updated to Mandatory REQ_UDS 0180: Modifcations on the bit values and new bit added REQ_UDS 0193: 0x05 is changed to Mandatory 6 Normative references: Updated the referenced documents and versions Removed Requirements and infos: REQ_UDS 0045: (0x86) service removed REQ_UDS 0053, REQ_UDS 0054: Removed the reserved DID ranges and 0xF1C1 REQ_UDS 0024: 0xF19E ODXFileDataIdentifier is removed 2024-10 First issue Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Information (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Secure communication and freshness protection | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS124.md · CVS124 > Page 90 · page 90 Estimation / resource / tool / IT / hardware impact Effort None, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00785 | RBAC for diagnostics Foreword This Commercial Vehicle Standard (“CVS151”) contains requirement specifications for TRATON Group and may be referred to by any of its commercial vehicle Affiliates.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | High Proposal Ready Open point: - | DetailsFull requirement text RBAC for diagnostics Foreword This Commercial Vehicle Standard (“CVS151”) contains requirement specifications for TRATON Group and may be referred to by any of its commercial vehicle Affiliates. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 1 · page 1 Estimation / resource / tool / IT / hardware impact Effort High, Competence Low, Tooling Medium, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00786 | Any review of this CVS151 shall only be done in agreement with the involved TRATON Group commercial vehicle Affiliates stated in the table below under section “Technical responsibility”.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-SYS-009 | Low Proposal Ready Open point: - | DetailsFull requirement text Any review of this CVS151 shall only be done in agreement with the involved TRATON Group commercial vehicle Affiliates stated in the table below under section “Technical responsibility”. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-SYS-009 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 1 · page 1 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00787 | The User shall apply the latest version of this CVS151.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text The User shall apply the latest version of this CVS151. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 1 · page 1 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00788 | Page 3 1 Scope Concepts such as secure-update (CVS37) requires Role Based Access Control (RBAC) for diagnostics (UDS).Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Validate assumption with customer; complete mapping; implement. | Diagnostic security | Feature / interface: Diagnostic security Architecture: Security Services SSR: SSR-RBAC-001 | High Proposal Ready Open point: - | DetailsFull requirement text Page 3 1 Scope Concepts such as secure-update (CVS37) requires Role Based Access Control (RBAC) for diagnostics (UDS). Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Diagnostic security | Security capability: Diagnostic security | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-001 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 3 · page 3 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00789 | RBAC_INFO 2 Before a client can execute diagnostics services that are under RBAC, the client must perform some type of authorization procedure towards the server/ECU.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Hardware platform support Architecture: Hardware Platform SSR: SSR-RBAC-005 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text RBAC_INFO 2 Before a client can execute diagnostics services that are under RBAC, the client must perform some type of authorization procedure towards the server/ECU. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Hardware platform support | Security capability: None | Interface: None | Architecture: Hardware Platform | Work product: System/architecture design | SSR: SSR-RBAC-005 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 4 · page 4 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Medium, IT High, HW/Test High Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00790 | RBAC_REQ 1 Each RBACC shall only contain one role-configuration per each supported role.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-RBAC-006 | Low Proposal Ready Open point: - | DetailsFull requirement text RBAC_REQ 1 Each RBACC shall only contain one role-configuration per each supported role. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-RBAC-006 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 4 · page 4 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00791 | RBAC_REQ 2 If conflicting/overlapping rules are found within a role-configuration, the server shall enforce that deny rule takes precedence over the allow rule.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text RBAC_REQ 2 If conflicting/overlapping rules are found within a role-configuration, the server shall enforce that deny rule takes precedence over the allow rule. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 5 · page 5 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00792 | RBAC_REQ 3 If a matching allow/deny rule is found and all the rule settings are fulfilled, the server shall accept/deny the request.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text RBAC_REQ 3 If a matching allow/deny rule is found and all the rule settings are fulfilled, the server shall accept/deny the request. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 5 · page 5 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00793 | RBAC_REQ 4 If a matching rule is found and not all the rule settings are fulfilled, the server shall consider the request rejected for that rule.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text RBAC_REQ 4 If a matching rule is found and not all the rule settings are fulfilled, the server shall consider the request rejected for that rule. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 5 · page 5 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00794 | RBAC_REQ 5 The server shall deny a request if no matching rule is found on RBACC.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text RBAC_REQ 5 The server shall deny a request if no matching rule is found on RBACC. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 5 · page 5 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00795 | RBAC_INFO 10 All RBACC ALLOW rules have a setting that dictates if a request, matching the rule, must be 14229-1:2020).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-RBAC-006 | Medium Proposal Ready Open point: - | DetailsFull requirement text RBAC_INFO 10 All RBACC ALLOW rules have a setting that dictates if a request, matching the rule, must be 14229-1:2020). Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-RBAC-006 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 5 · page 5 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00796 | RBAC_REQ 6 The server shall evaluate each role-configuration independently from each other.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text RBAC_REQ 6 The server shall evaluate each role-configuration independently from each other. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00797 | RBAC_REQ 27 The server shall require that requests are authenticated for allow rules, using e.g., SecuredDataTransmission 0x84 (see CVS31, ISO-14229-1:2020).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text RBAC_REQ 27 The server shall require that requests are authenticated for allow rules, using e.g., SecuredDataTransmission 0x84 (see CVS31, ISO-14229-1:2020). Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00798 | Page 7 RBACC Role-configuration role Pattern-rule DENY Pattern-rule ALLOW DID-rule DENY DID-rule ALLOW RID-rule DENY RID-rule ALLOW Figure 2 – Visual representation of the RBACC 3.3 ASN.1 definition RBAC_REQ 7 The server and client shall define the RBACC as per the following ASN.1 definition: RBACC ::= SEQUENCE { version OCTET STRING (SIZE(2)), rbacc-id OCTET STRING (SIZE(16)), role-configurations SEQUENCE (SIZE(0..MAX)) OF Role-configuration } Role-configuration ::= SEQUENCE { role INTEGER(0..MAX), pattern-rules-deny SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(2..MAX)), pattern-rules-allow SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(2..MAX)), did-rules-deny SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(3)), did-rules-allow SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(3)), rid-rules-deny SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(3)), rid-rules-allow SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(3)) }Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text Page 7 RBACC Role-configuration role Pattern-rule DENY Pattern-rule ALLOW DID-rule DENY DID-rule ALLOW RID-rule DENY RID-rule ALLOW Figure 2 – Visual representation of the RBACC 3.3 ASN.1 definition RBAC_REQ 7 The server and client shall define the RBACC as per the following ASN.1 definition: RBACC ::= SEQUENCE { version OCTET STRING (SIZE(2)), rbacc-id OCTET STRING (SIZE(16)), role-configurations SEQUENCE (SIZE(0..MAX)) OF Role-configuration } Role-configuration ::= SEQUENCE { role INTEGER(0..MAX), pattern-rules-deny SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(2..MAX)), pattern-rules-allow SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(2..MAX)), did-rules-deny SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(3)), did-rules-allow SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(3)), rid-rules-deny SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(3)), rid-rules-allow SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(3)) } Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 7 · page 7 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00799 | RBAC_REQ 8 The server shall support in the version field two octets.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text RBAC_REQ 8 The server shall support in the version field two octets. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00800 | RBAC_REQ 9 The server shall support major version value 3 and minor version value 0.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text RBAC_REQ 9 The server shall support major version value 3 and minor version value 0. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00801 | RBAC_INFO 19 If other versions shall be supported is out of the scope of this document and shall be agreed upon between projects in Traton.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-RBAC-006 | Medium Proposal Ready Open point: - | DetailsFull requirement text RBAC_INFO 19 If other versions shall be supported is out of the scope of this document and shall be agreed upon between projects in Traton. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-RBAC-006 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00802 | RBAC_REQ 10 Before RBACC is stored, the server shall verify that the server supports the structure indicated in the version number.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text RBAC_REQ 10 Before RBACC is stored, the server shall verify that the server supports the structure indicated in the version number. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00803 | If the version number does not comply with the server implementation, the server shall reject storing the data.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text If the version number does not comply with the server implementation, the server shall reject storing the data. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00804 | RBAC_REQ 11 The server shall report the currently stored RBACC’s version via diagnostics.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text RBAC_REQ 11 The server shall report the currently stored RBACC’s version via diagnostics. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Medium, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00805 | RBAC_REQ 12 The server shall support 16 octets in the rbacc-id field.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text RBAC_REQ 12 The server shall support 16 octets in the rbacc-id field. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00806 | RBAC_REQ 13 The server shall report the currently stored RBACC’s rbacc-id via diagnostics.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text RBAC_REQ 13 The server shall report the currently stored RBACC’s rbacc-id via diagnostics. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Medium, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00807 | RBAC_REQ 14 The server shall support role-configurations using 32-bit unsigned integer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text RBAC_REQ 14 The server shall support role-configurations using 32-bit unsigned integer. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00808 | Page 9 3.7 pattern-rules RBAC_REQ 15 The server shall support for every entry in the pattern-rules one octet for the pattern rule settings followed by the diagnostic pattern of variable length.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Diagnostic security | Feature / interface: Diagnostic security Architecture: Security Services SSR: SSR-RBAC-001 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text Page 9 3.7 pattern-rules RBAC_REQ 15 The server shall support for every entry in the pattern-rules one octet for the pattern rule settings followed by the diagnostic pattern of variable length. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Diagnostic security | Security capability: Diagnostic security | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-001 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00809 | RBAC_REQ 16 The server shall support the pattern-rule setting according to Table 1.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text RBAC_REQ 16 The server shall support the pattern-rule setting according to Table 1. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00810 | Table 1 – Pattern Rule Settings Bit index Name Description 0 Reserved Reserved 1 UDS 0 == This rule is not valid for a UDS-server 1 == This rule is valid for a UDS-server This bit shall always assume value 1 2 Reserved Reserved 3 Confidentiality 0 == No confidentiality is required on the diagnostics request 1 == Confidentiality is required on the diagnostics request e.g., 0x84 (CVS32) Note: This bit is supported but not used for deny rules.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-DIAG-003 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text Table 1 – Pattern Rule Settings Bit index Name Description 0 Reserved Reserved 1 UDS 0 == This rule is not valid for a UDS-server 1 == This rule is valid for a UDS-server This bit shall always assume value 1 2 Reserved Reserved 3 Confidentiality 0 == No confidentiality is required on the diagnostics request 1 == Confidentiality is required on the diagnostics request e.g., 0x84 (CVS32) Note: This bit is supported but not used for deny rules. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-DIAG-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Medium, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00811 | 4-7 N/A Reserved for future use 3.8 did-rules RBAC_REQ 17 The server shall support for every entry in the did-rules one octet which represents the did-rule settings followed by two octets that represent the DID.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text 4-7 N/A Reserved for future use 3.8 did-rules RBAC_REQ 17 The server shall support for every entry in the did-rules one octet which represents the did-rule settings followed by two octets that represent the DID. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00812 | RBAC_REQ 18 The byte order for DID shall be big endian.Expectation: Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-RBAC-006 | Medium Proposal Ready Open point: - | DetailsFull requirement text RBAC_REQ 18 The byte order for DID shall be big endian. Engineering expectation Supplier is expected to provide cybersecurity work products and evidence showing how embedded cybersecurity is managed across the lifecycle. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-RBAC-006 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00813 | RBAC_REQ 19 The server shall support the did-rule setting according to Table 2.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text RBAC_REQ 19 The server shall support the did-rule setting according to Table 2. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00814 | Page 10 Table 2 – DID Rule Settings Bit index Name Description 0 Reserved Reserved 1 UDS 0 == This rule is not valid for a UDS-server 1 == This rule is valid for a UDS-server This bit shall always assume value 1 2 Reserved Reserved 3 Confidentiality 0 == No confidentiality is required on the diagnostics request 1 == Confidentiality is required on the diagnostics request e.g., 0x84 (CVS32) Note: This bit is supported but not used for deny rules.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-DIAG-003 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text Page 10 Table 2 – DID Rule Settings Bit index Name Description 0 Reserved Reserved 1 UDS 0 == This rule is not valid for a UDS-server 1 == This rule is valid for a UDS-server This bit shall always assume value 1 2 Reserved Reserved 3 Confidentiality 0 == No confidentiality is required on the diagnostics request 1 == Confidentiality is required on the diagnostics request e.g., 0x84 (CVS32) Note: This bit is supported but not used for deny rules. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-DIAG-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Medium, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00815 | 4 Read 0 == This rule is not applicable when the DID is being read 1 == This rule is applicable when the DID is being read 5 Write 0 == This rule is not applicable when the DID is being written 1 == This rule is applicable when the DID is being written 6 IO-control 0 == This rule is not applicable when the DID is being used for IO-control 1 == This rule is applicable when the DID is being used for IO-control 7 N/A Reserved for future use 3.9 rid-rules RBAC_REQ 20 The server shall support for every entry in the rid-rules one octet which represents the rid-rule settings followed by two octets that represent the RID.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text 4 Read 0 == This rule is not applicable when the DID is being read 1 == This rule is applicable when the DID is being read 5 Write 0 == This rule is not applicable when the DID is being written 1 == This rule is applicable when the DID is being written 6 IO-control 0 == This rule is not applicable when the DID is being used for IO-control 1 == This rule is applicable when the DID is being used for IO-control 7 N/A Reserved for future use 3.9 rid-rules RBAC_REQ 20 The server shall support for every entry in the rid-rules one octet which represents the rid-rule settings followed by two octets that represent the RID. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00816 | RBAC_REQ 21 The server shall support the rid-rule setting according to Table 3.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text RBAC_REQ 21 The server shall support the rid-rule setting according to Table 3. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00817 | Page 11 Table 3 – RID Rule Setting Bit index Name Description 0 Reserved Reserved 1 UDS 0 == This rule is not valid for a UDS-server 1 == This rule is valid for a UDS-server This bit shall always assume value 1 2 Reserved Reserved 3 Confidentiality 0 == No confidentiality is required on the diagnostics request 1 == Confidentiality is required on the diagnostics request e.g., 0x84 (CVS32) Note: This bit is supported but not used for deny rules.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-DIAG-003 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text Page 11 Table 3 – RID Rule Setting Bit index Name Description 0 Reserved Reserved 1 UDS 0 == This rule is not valid for a UDS-server 1 == This rule is valid for a UDS-server This bit shall always assume value 1 2 Reserved Reserved 3 Confidentiality 0 == No confidentiality is required on the diagnostics request 1 == Confidentiality is required on the diagnostics request e.g., 0x84 (CVS32) Note: This bit is supported but not used for deny rules. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-DIAG-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Medium, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00818 | RBAC_REQ 22 If conflicting/overlapping rules are found between the client certificate D-RBACC extension and any rules in the RBAC-configuration in the RBACC, the server shall enforce the rules in the client certificate D-RBACC extension.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Certificate handling | Feature / interface: Certificate handling Architecture: Security Services SSR: SSR-KEY-002 | High Proposal Ready Open point: OP-003 | DetailsFull requirement text RBAC_REQ 22 If conflicting/overlapping rules are found between the client certificate D-RBACC extension and any rules in the RBAC-configuration in the RBACC, the server shall enforce the rules in the client certificate D-RBACC extension. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-003 Traceability Feature: Certificate handling | Security capability: Certificate handling | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-KEY-002 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00819 | Page 12 RBAC_REQ 23 The server shall interpret the extnValue (see snipped above) as of one instance of a RBACC (see 3.3).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text Page 12 RBAC_REQ 23 The server shall interpret the extnValue (see snipped above) as of one instance of a RBACC (see 3.3). Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00820 | It can also be useful if you want to add or remove access rights from a client/tester, that needs access to one or several roles, but should not have access to everything (or should have more access) specified for the assigned roles.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-003 | Low Proposal Ready Open point: OP-002 | DetailsFull requirement text It can also be useful if you want to add or remove access rights from a client/tester, that needs access to one or several roles, but should not have access to everything (or should have more access) specified for the assigned roles. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Medium, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00821 | 3.11 ECU-Diagnostics-Role Extension RBAC_REQ 36 The server shall exert the RBACC roles based on the ECU-diagnostics-Role extension on the client’s certificate.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Certificate handling | Feature / interface: Certificate handling Architecture: Security Services SSR: SSR-KEY-002 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text 3.11 ECU-Diagnostics-Role Extension RBAC_REQ 36 The server shall exert the RBACC roles based on the ECU-diagnostics-Role extension on the client’s certificate. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Certificate handling | Security capability: Certificate handling | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-KEY-002 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00822 | Page 13 Figure 3 – Logic Overview RBAC_REQ 35 The server shall implement RBAC internal logic as per Figure 4.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-RBAC-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text Page 13 Figure 3 – Logic Overview RBAC_REQ 35 The server shall implement RBAC internal logic as per Figure 4. Engineering expectation Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-RBAC-004 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 13 · page 13 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00823 | RBAC_REQ 32 The server shall implement RBAC pattern rule evaluation logic as per Figure 5.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-RBAC-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text RBAC_REQ 32 The server shall implement RBAC pattern rule evaluation logic as per Figure 5. Engineering expectation Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-RBAC-004 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 15 · page 15 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00824 | E.g: For the evaluate pattern the rule setting Confidentiality is set to 0x01 (Confidentiality is required).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text E.g: For the evaluate pattern the rule setting Confidentiality is set to 0x01 (Confidentiality is required). Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 16 · page 16 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00825 | RBAC_REQ 33 The server shall implement RBAC did rule evaluate as per Figure 6.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text RBAC_REQ 33 The server shall implement RBAC did rule evaluate as per Figure 6. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 16 · page 16 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00826 | Page 17 RBAC_REQ 34 The server shall implement RBAC rid rule evaluate as per Figure 7.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text Page 17 RBAC_REQ 34 The server shall implement RBAC rid rule evaluate as per Figure 7. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 17 · page 17 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00827 | Meaning, role 0 is particularly useful for defining services, DIDs and RIDs that should be available to all clients/users, regardless of their diagnostics role and/or authorization/authentication status.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-RBAC-006 | High Proposal Ready Open point: - | DetailsFull requirement text Meaning, role 0 is particularly useful for defining services, DIDs and RIDs that should be available to all clients/users, regardless of their diagnostics role and/or authorization/authentication status. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-RBAC-006 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 19 · page 19 Estimation / resource / tool / IT / hardware impact Effort High, Competence Low, Tooling Medium, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00828 | RBAC_REQ 24 The server shall allow requests that are contained in role 0 rules regardless of the client authentication state.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | High Proposal Ready Open point: - | DetailsFull requirement text RBAC_REQ 24 The server shall allow requests that are contained in role 0 rules regardless of the client authentication state. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 19 · page 19 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00829 | RBAC_REQ 25 The server shall allow request that are contained in role 0 rule regardless if the request is data authenticated e.g over e.g., SecuredDataTransmission 0x84 (See CVS31, ISO 14229-1:2020).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text RBAC_REQ 25 The server shall allow request that are contained in role 0 rule regardless if the request is data authenticated e.g over e.g., SecuredDataTransmission 0x84 (See CVS31, ISO 14229-1:2020). Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 19 · page 19 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00830 | RBAC_REQ 26 The server shall allow request that are contained in role 0 rule regardless of the value of Confidentiality field setting.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text RBAC_REQ 26 The server shall allow request that are contained in role 0 rule regardless of the value of Confidentiality field setting. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 19 · page 19 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00831 | RBAC_INFO 40 This means that in role 0 encryption is never required.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-RBAC-006 | Medium Proposal Ready Open point: - | DetailsFull requirement text RBAC_INFO 40 This means that in role 0 encryption is never required. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-RBAC-006 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 19 · page 19 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00832 | 3.14 Requests Specific Requirements 3.14.1 Diagnostic over USD 3.14.1.1 Authenticate 0x29 RBAC_REQ 28 The server shall always allow reception of UDS authenticate 0x29 requests regardless of the RBACC settings.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Authentication | Feature / interface: Authentication Architecture: Security Services SSR: SSR-RBAC-002 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text 3.14 Requests Specific Requirements 3.14.1 Diagnostic over USD 3.14.1.1 Authenticate 0x29 RBAC_REQ 28 The server shall always allow reception of UDS authenticate 0x29 requests regardless of the RBACC settings. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Authentication | Security capability: Authentication | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-002 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 19 · page 19 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00833 | RBAC_INFO 42 For 0x29 requests a corresponding matching rule in the RBACC is not required for the server to accept the request.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text RBAC_INFO 42 For 0x29 requests a corresponding matching rule in the RBACC is not required for the server to accept the request. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 19 · page 19 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00834 | 3.14.1.2 SecuredData Transmission 0x84 RBAC_REQ 29 The server shall evaluate the reported internal service using the RBACC rules whenever it receives a UDS Service 0x84 requests.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-RBAC-004 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text 3.14.1.2 SecuredData Transmission 0x84 RBAC_REQ 29 The server shall evaluate the reported internal service using the RBACC rules whenever it receives a UDS Service 0x84 requests. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-RBAC-004 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 19 · page 19 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00835 | RBAC_REQ 30 The server shall always allow reception of UDS SecuredDataTransmission 0x84 requests regardless of the RBACC settings.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text RBAC_REQ 30 The server shall always allow reception of UDS SecuredDataTransmission 0x84 requests regardless of the RBACC settings. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 19 · page 19 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00836 | RBAC_INFO 43 For 0x84 requests a corresponding matching rule in the RBACC is not required for the server to accept the 0x84 request but the server must find a corresponding matching rule for the internal request contained in the 0x84 prior to execute it.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text RBAC_INFO 43 For 0x84 requests a corresponding matching rule in the RBACC is not required for the server to accept the 0x84 request but the server must find a corresponding matching rule for the internal request contained in the 0x84 prior to execute it. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 19 · page 19 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00837 | Page 20 3.14.1.3 TesterPresent 0x3E RBAC_REQ 31 The server shall always allow reception of UDS TesterPresent 0x3E requests regardless of the RBACC settings.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text Page 20 3.14.1.3 TesterPresent 0x3E RBAC_REQ 31 The server shall always allow reception of UDS TesterPresent 0x3E requests regardless of the RBACC settings. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 20 · page 20 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00838 | RBAC_INFO 44 For 0x3E requests a corresponding matching rule in the RBACC is not required for the server to accept the request.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text RBAC_INFO 44 For 0x3E requests a corresponding matching rule in the RBACC is not required for the server to accept the request. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 20 · page 20 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00839 | Page 26 Annex D DynamicallyDefineDataIdentifier When this service is being used, each DID included in the request must be evaluated against the rules that are applicable for the client (the rules in the client’s certificate and in the RBACC).Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Accept with Assumption | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Validate assumption with customer; complete mapping; implement. | Certificate handling | Feature / interface: Certificate handling Architecture: Security Services SSR: SSR-KEY-002 | High Proposal Ready Open point: - | DetailsFull requirement text Page 26 Annex D DynamicallyDefineDataIdentifier When this service is being used, each DID included in the request must be evaluated against the rules that are applicable for the client (the rules in the client’s certificate and in the RBACC). Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Certificate handling | Security capability: Certificate handling | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-KEY-002 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 26 · page 26 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00840 | The client must have read access for all included DIDs and have access to the service themselves.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-008 | Medium Proposal Ready Open point: - | DetailsFull requirement text The client must have read access for all included DIDs and have access to the service themselves. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-008 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 26 · page 26 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00841 | When the client is performing the actual read operation (ReadDataByIdentifier [7]), the conditions and rules for all DIDs, aliased by the dynamically defined identifier, must be met, otherwise the request shall be rejected with an appropriate NRC.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text When the client is performing the actual read operation (ReadDataByIdentifier [7]), the conditions and rules for all DIDs, aliased by the dynamically defined identifier, must be met, otherwise the request shall be rejected with an appropriate NRC. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 26 · page 26 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00842 | Since reading of DIDs can be allowed by either a pattern-rule (starting with 22 [7]) and/or a DID-rule, both the pattern-rules and the DID-rules must be parsed when evaluating each DID.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text Since reading of DIDs can be allowed by either a pattern-rule (starting with 22 [7]) and/or a DID-rule, both the pattern-rules and the DID-rules must be parsed when evaluating each DID. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/CVS151.md · CVS151 > Page 26 · page 26 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00843 | Data Security Container base definition Foreword This Commercial Vehicle Standard (“CVS154”) contains requirement specifications for TRATON Group and may be referred to by any of its commercial vehicle Affiliates.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | High Proposal Ready Open point: - | DetailsFull requirement text Data Security Container base definition Foreword This Commercial Vehicle Standard (“CVS154”) contains requirement specifications for TRATON Group and may be referred to by any of its commercial vehicle Affiliates. Engineering expectation Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Cybersecurity control (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 1 · page 1 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00844 | Any review of this CVS154 shall only be done in agreement with the involved TRATON Group commercial vehicle Affiliates stated in the table below under section “Technical responsibility”.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-SYS-009 | Low Proposal Ready Open point: - | DetailsFull requirement text Any review of this CVS154 shall only be done in agreement with the involved TRATON Group commercial vehicle Affiliates stated in the table below under section “Technical responsibility”. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-SYS-009 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 1 · page 1 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00845 | The User shall apply the latest version of this CVS154.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text The User shall apply the latest version of this CVS154. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 1 · page 1 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00846 | This document shall be used accompanied with these specifications.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text This document shall be used accompanied with these specifications. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 3 · page 3 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00847 | DSC_BASE_REQ 37 The server shall support a DSC Metadata block containing version and id fields.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text DSC_BASE_REQ 37 The server shall support a DSC Metadata block containing version and id fields. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 5 · page 5 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00848 | DSC_BASE_REQ 43 The server shall support the Major and Minor version as specified in 3.2.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text DSC_BASE_REQ 43 The server shall support the Major and Minor version as specified in 3.2. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 5 · page 5 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00849 | DSC_BASE_REQ 29 The server shall support a DSC containing verificationEntries.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration; Security evidence and traceability / OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface SSR: SSR-VV-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text DSC_BASE_REQ 29 The server shall support a DSC containing verificationEntries. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Backend and IT Systems; OEM/Customer Review Interface | Work product: Requirement traceability record | SSR: SSR-VV-002 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 5 · page 5 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00850 | DSC_BASE_REQ 30 The server shall support a DSC containing encryptionEntries.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text DSC_BASE_REQ 30 The server shall support a DSC containing encryptionEntries. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 5 · page 5 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00851 | DSC_BASE_REQ 31 The server shall support a DSC containing itemEntries.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text DSC_BASE_REQ 31 The server shall support a DSC containing itemEntries. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 5 · page 5 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00852 | DSC_BASE_REQ 45 The server shall expect an ASN.1 SEQUENCE tag with length zero for verificationEntries that contains no VerificationEntry items in a DSC transmitted by the client.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration; Security evidence and traceability / OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface SSR: SSR-VV-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text DSC_BASE_REQ 45 The server shall expect an ASN.1 SEQUENCE tag with length zero for verificationEntries that contains no VerificationEntry items in a DSC transmitted by the client. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Backend and IT Systems; OEM/Customer Review Interface | Work product: Requirement traceability record | SSR: SSR-VV-002 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 5 · page 5 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00853 | DSC_BASE_REQ 46 The server shall expect an ASN.1 SEQUENCE tag with length zero for encryptionEntries that contains no EncryptionEntry items in a DSC transmitted by the client.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text DSC_BASE_REQ 46 The server shall expect an ASN.1 SEQUENCE tag with length zero for encryptionEntries that contains no EncryptionEntry items in a DSC transmitted by the client. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 5 · page 5 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00854 | DSC_BASE_REQ 49 The server shall expect an ASN.1 SEQUENCE tag with length zero for ItemEntries that contains no items in a DSC transmitted by the client.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text DSC_BASE_REQ 49 The server shall expect an ASN.1 SEQUENCE tag with length zero for ItemEntries that contains no items in a DSC transmitted by the client. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 5 · page 5 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00855 | DSC_BASE_REQ 26 The server shall support an empty DSC containing only Metadata (version and id) and the empty sequences for verificationEntries, encryptionEntries and ItemEntries.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration; Security evidence and traceability / OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface SSR: SSR-VV-002 | Low Proposal Ready Open point: - | DetailsFull requirement text DSC_BASE_REQ 26 The server shall support an empty DSC containing only Metadata (version and id) and the empty sequences for verificationEntries, encryptionEntries and ItemEntries. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Backend and IT Systems; OEM/Customer Review Interface | Work product: Requirement traceability record | SSR: SSR-VV-002 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 5 · page 5 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00856 | DSC_BASE_INFO 44 An empty DSC issued by client means that in addition to Metadata, the syntax must be correct in accordance with Annex B.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text DSC_BASE_INFO 44 An empty DSC issued by client means that in addition to Metadata, the syntax must be correct in accordance with Annex B. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 5 · page 5 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00857 | Page 6 DSC_BASE_INFO 33 A DSC containing only version and id states that verification and encryption is not to be performed by the server, although the server shall have the support.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration; Security evidence and traceability / OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface SSR: SSR-VV-002 | Low Proposal Ready Open point: - | DetailsFull requirement text Page 6 DSC_BASE_INFO 33 A DSC containing only version and id states that verification and encryption is not to be performed by the server, although the server shall have the support. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Backend and IT Systems; OEM/Customer Review Interface | Work product: Requirement traceability record | SSR: SSR-VV-002 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00858 | 3.1.1.1 HashCmp DSC_BASE_REQ 5 VerificationEntry hashCmp states that a hash comparison shall be used to verify the data.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Security evidence and traceability / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-VV-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text 3.1.1.1 HashCmp DSC_BASE_REQ 5 VerificationEntry hashCmp states that a hash comparison shall be used to verify the data. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-VV-001 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00859 | However, the instance specification may state specialized actions: • Server processes each VerificationEntry one by one.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: Security evidence and traceability Architecture: None SSR: None | Low Proposal Ready Open point: - | DetailsFull requirement text However, the instance specification may state specialized actions: • Server processes each VerificationEntry one by one. Engineering expectation Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Non-functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Security evidence and traceability | Security capability: None | Interface: None | Architecture: None | Work product: Requirement traceability record | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT High, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00860 | Page 7 • hashAlgorithm: States which HashAlgorithm (see RFC 6234) shall be used for hashing the data to verify.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text Page 7 • hashAlgorithm: States which HashAlgorithm (see RFC 6234) shall be used for hashing the data to verify. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 7 · page 7 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00861 | • dataRanges: sequence of Range itemsRange: Information on which data chunks that shall be verified.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-CON-002 | High Proposal Ready Open point: - | DetailsFull requirement text • dataRanges: sequence of Range items - Range: Information on which data chunks that shall be verified. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-CON-002 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 7 · page 7 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00862 | DSC_BASE_REQ 47 The server shall support the SHA512 HashAlgorithm as referred in 3.2 ASN1 definition.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text DSC_BASE_REQ 47 The server shall support the SHA512 HashAlgorithm as referred in 3.2 ASN1 definition. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 7 · page 7 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00863 | DSC_BASE_REQ 39 For crypto agility reasons, both of the choices shall be supported by the server.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | High Proposal Ready Open point: - | DetailsFull requirement text DSC_BASE_REQ 39 For crypto agility reasons, both of the choices shall be supported by the server. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 7 · page 7 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00864 | DSC_BASE_REQ 11 The initial counter value shall be set to 0 (zero).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text DSC_BASE_REQ 11 The initial counter value shall be set to 0 (zero). Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 7 · page 7 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00865 | Range: Information on which data chunks that shall be decrypted.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text Range: Information on which data chunks that shall be decrypted. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00866 | 3.2 DSC ASN.1 definition DSC_BASE_REQ 41 The structure version for this document release shall be: Major ‘04’ and Minor ‘00’ DSC_BASE_REQ 42 The server shall have support for the ASN.1 contents as defined: DataSecurityContainer ::= SEQUENCE { version OCTET STRING (SIZE(2)), id OCTET STRING (SIZE(16)), verificationEntries SEQUENCE (SIZE(0..MAX)) OF VerificationEntry, encryptionEntries SEQUENCE (SIZE(0..MAX)) OF EncryptionEntry, itemEntries SEQUENCE (SIZE(0..MAX)) OF ItemEntry } VerificationEntry ::= CHOICE { hashCmp [0] EXPLICIT HashCmp }Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Needs Customer Clarification | Needs customer clarification. The requirement implies customer-owned infrastructure, approval, or a responsibility split that is not yet available.Decision: Send linked open point to the customer for decision. | None | Feature / interface: Backend and IT integration; Security evidence and traceability / OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface SSR: None | Unknown Reviewed Internally Open point: OP-011 | DetailsFull requirement text 3.2 DSC ASN.1 definition DSC_BASE_REQ 41 The structure version for this document release shall be: Major ‘04’ and Minor ‘00’ DSC_BASE_REQ 42 The server shall have support for the ASN.1 contents as defined: DataSecurityContainer ::= SEQUENCE { version OCTET STRING (SIZE(2)), id OCTET STRING (SIZE(16)), verificationEntries SEQUENCE (SIZE(0..MAX)) OF VerificationEntry, encryptionEntries SEQUENCE (SIZE(0..MAX)) OF EncryptionEntry, itemEntries SEQUENCE (SIZE(0..MAX)) OF ItemEntry } VerificationEntry ::= CHOICE { hashCmp [0] EXPLICIT HashCmp } Engineering expectation Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Supplier proposal Needs customer clarification. The requirement implies customer-owned infrastructure, approval, or a responsibility split that is not yet available. Rationale Flagged customer_clarification_needed=yes during extraction. Implementation approach Hold implementation; raise an open point and a clarification question. Acceptance condition Customer answers the linked open point. Customer feedback - Customer decision - Customer clarification / open point Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline. Traceability Feature: Backend and IT integration; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Backend and IT Systems; OEM/Customer Review Interface | Work product: Requirement traceability record | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort Unknown, Competence Medium, Tooling Low, IT High, HW/Test Medium Risk if unresolved Scope and effort cannot be frozen; estimation carries an open assumption and downstream design may rework. Next action Send linked open point to the customer for decision. |
| REQ-AUTO-00867 | DSC_BASE_REQ 19 Upon reception of a DSC to the server, before the DSC is stored in NVM, the DSC shall be semantically verified by parsing all its content.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Secure communication and freshness protection; Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-006 | Medium Proposal Ready Open point: - | DetailsFull requirement text DSC_BASE_REQ 19 Upon reception of a DSC to the server, before the DSC is stored in NVM, the DSC shall be semantically verified by parsing all its content. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Secure communication and freshness protection; Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-006 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00868 | DSC_BASE_REQ 51 The length of the version field shall be verified.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text DSC_BASE_REQ 51 The length of the version field shall be verified. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ_DSC_BASE-20 | REQ_DSC_BASE 20 The version shall be verified with the servers supported Major and Minor version of the DSC logic for compliancy.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-008 | Medium Proposal Ready Open point: - | DetailsFull requirement text REQ_DSC_BASE 20 The version shall be verified with the servers supported Major and Minor version of the DSC logic for compliancy. Engineering expectation Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-008 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00870 | DSC_BASE_REQ 34 The length of the id field shall be verified.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text DSC_BASE_REQ 34 The length of the id field shall be verified. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00871 | DSC_BASE_REQ 27 The hashAlgorithm shall be supported by the server.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text DSC_BASE_REQ 27 The hashAlgorithm shall be supported by the server. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00872 | Page 11 DSC_BASE_REQ 50 The length of every referenceHash shall be consistent with the output size of the hash algorithm specified in the hashAlgorithm.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text Page 11 DSC_BASE_REQ 50 The length of every referenceHash shall be consistent with the output size of the hash algorithm specified in the hashAlgorithm. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00873 | DSC_BASE_INFO 35 The verification of servers support of specified dataRanges in the VerificationEntry, shall be stated for the DSC instance.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: System behavior; Security evidence and traceability / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-VV-001 | High Proposal Ready Open point: OP-001 | DetailsFull requirement text DSC_BASE_INFO 35 The verification of servers support of specified dataRanges in the VerificationEntry, shall be stated for the DSC instance. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-001 Traceability Feature: System behavior; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-VV-001 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00874 | DSC_BASE_REQ 28 The EncryptionEntry algorithm shall be supported by the server.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text DSC_BASE_REQ 28 The EncryptionEntry algorithm shall be supported by the server. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00875 | DSC_BASE_REQ 22 The length of key and iv shall be verified accordingly to the algorithm stipulated in EncryptionEntry.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | Key management | Feature / interface: Key management Architecture: Security Services SSR: SSR-KEY-001 | High Proposal Ready Open point: - | DetailsFull requirement text DSC_BASE_REQ 22 The length of key and iv shall be verified accordingly to the algorithm stipulated in EncryptionEntry. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Key management | Security capability: Key management | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-KEY-001 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00876 | DSC_BASE_INFO 36 The verification of servers support of specified dataRanges in the EncryptionEntry, shall be stated for the DSC instance.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: System behavior; Security evidence and traceability / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-VV-001 | High Proposal Ready Open point: OP-001 | DetailsFull requirement text DSC_BASE_INFO 36 The verification of servers support of specified dataRanges in the EncryptionEntry, shall be stated for the DSC instance. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-001 Traceability Feature: System behavior; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-VV-001 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00877 | DSC_BASE_REQ 48 If the DSC instance is rejected by the server (see Annex A) when transmitted with EMP, an error code shall be returned to the client.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text DSC_BASE_REQ 48 If the DSC instance is rejected by the server (see Annex A) when transmitted with EMP, an error code shall be returned to the client. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00878 | The sequence tags for verificationEntries, encryptionEntries and itemEntries are required but empty (zero length).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Security evidence and traceability / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-VV-001 | Medium Proposal Ready Open point: - | DetailsFull requirement text The sequence tags for verificationEntries, encryptionEntries and itemEntries are required but empty (zero length). Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-VV-001 Source PDF Source evidence converted/markdown-cleaned/CVS154.md · CVS154 > Page 14 · page 14 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00879 | The User shall apply the latest version of this CVS31.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text The User shall apply the latest version of this CVS31. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 1 · page 1 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00880 | Internal Page 3 (31) Foreword This CVS31 contains requirement specification for TRATON GROUP and may be used by all within TRATON Group, if applicable.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | Low Proposal Ready Open point: - | DetailsFull requirement text Internal Page 3 (31) Foreword This CVS31 contains requirement specification for TRATON GROUP and may be used by all within TRATON Group, if applicable. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 3 · page 3 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00881 | Any review of CVS31 shall only be done in agreement with the involved departments stated in the table on the first page under section “Technical responsibility”.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-SYS-009 | Low Proposal Ready Open point: - | DetailsFull requirement text Any review of CVS31 shall only be done in agreement with the involved departments stated in the table on the first page under section “Technical responsibility”. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-SYS-009 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 3 · page 3 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00882 | The whole standard has been reworked and shall be read in its entirety.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text The whole standard has been reworked and shall be read in its entirety. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 3 · page 3 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00883 | • Affiliate means any legal entity that directly or indirectly controls, is controlled by, or is commonly controlled with TRATON SE, it is being understood that “control” shall mean ownership of at least 50% of the voting rights or interest in the issued share capital, including for the avoidance of doubt any branch.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | Low Proposal Ready Open point: - | DetailsFull requirement text • Affiliate means any legal entity that directly or indirectly controls, is controlled by, or is commonly controlled with TRATON SE, it is being understood that “control” shall mean ownership of at least 50% of the voting rights or interest in the issued share capital, including for the avoidance of doubt any branch. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 3 · page 3 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00884 | Any deviations from this specification shall be documented and must be reviewed by the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text Any deviations from this specification shall be documented and must be reviewed by the vehicle manufacturer. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 4 · page 4 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00885 | Shall be agreed between the supplier and the vehicle manufacturer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior / OEM/Customer Review Interface Architecture: System Core; OEM/Customer Review Interface SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text Shall be agreed between the supplier and the vehicle manufacturer. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: System Core; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00886 | It contains the information required for the server to verify the client’s subsequent request and to generate the corresponding response.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text It contains the information required for the server to verify the client’s subsequent request and to generate the corresponding response. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00887 | It contains the information required for the server to maintain continuous authenticated communication with the client and to generate authenticated responses.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text It contains the information required for the server to maintain continuous authenticated communication with the client and to generate authenticated responses. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-003 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00888 | AUTH_REQ 1 The server shall only support subfunctions in Table 4.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | Low Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 1 The server shall only support subfunctions in Table 4. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 7 · page 7 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00889 | Table 4 – Supported subFunctions (ISO 14229-1:2020) Name verifyCertificateBidirectional proofOfOwnership deAuthenticate AUTH_REQ 155 The server shall not accept an application-layer service 0x29 request when it is received inside an SDT (service 0x84) protected message.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior; Secure communication and freshness protection Architecture: Application Software SSR: SSR-KEY-003 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text Table 4 – Supported subFunctions (ISO 14229-1:2020) Name verifyCertificateBidirectional proofOfOwnership deAuthenticate AUTH_REQ 155 The server shall not accept an application-layer service 0x29 request when it is received inside an SDT (service 0x84) protected message. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Application software behavior; Secure communication and freshness protection | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-KEY-003 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 7 · page 7 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling High, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00890 | If such an encapsulated 0x29 request is detected, the server shall return application-layer NRC 0x39, provided as a correctly formatted SDT positive response.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior; Secure communication and freshness protection Architecture: Application Software SSR: SSR-RBAC-004 | Medium Proposal Ready Open point: OP-002 | DetailsFull requirement text If such an encapsulated 0x29 request is detected, the server shall return application-layer NRC 0x39, provided as a correctly formatted SDT positive response. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Application software behavior; Secure communication and freshness protection | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-RBAC-004 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 7 · page 7 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00891 | Internal Page 8 (31) 3.1 verifyCertificateBidirectional 3.1.1 Request AUTH_REQ 2 The request for verifyCertificateBidirectional subfunction shall be formatted according to Table 5.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Accept with Assumption | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-KEY-004 | High Proposal Ready Open point: - | DetailsFull requirement text Internal Page 8 (31) 3.1 verifyCertificateBidirectional 3.1.1 Request AUTH_REQ 2 The request for verifyCertificateBidirectional subfunction shall be formatted according to Table 5. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-KEY-004 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling High, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00892 | Table 5 – verifyCertificateBidirectional Request Field Description Type/Value Cvt Included in proofOfOwnershipServer Authentication Request SID Service ID for Authentication service request 0x29 M Yes verifyCertificateBidirectional] Initiate Authentication by verifying the Certificate and generating a Proof of Ownership from the server 0x02 M Yes communicationConfiguration NOT USED 0x00 M Yes lengthOfCertificateClient Length parameter for certificateClient uint16 M Yes certificateClient The Certificate to verify uint8[] M Yes lengthOfChallengeClient Length parameter for challengeClient uint16 M Yes challengeClient See 3.1.1.1 uint8[] M Yes AUTH_REQ 117 Upon reception of a verifyCertificateBidirectional request, the server shall determine whether the Authentication delay timer is currently running.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Authentication | Feature / interface: Authentication Architecture: Security Services SSR: SSR-DAI-001 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text Table 5 – verifyCertificateBidirectional Request Field Description Type/Value Cvt Included in proofOfOwnershipServer Authentication Request SID Service ID for Authentication service request 0x29 M Yes verifyCertificateBidirectional] Initiate Authentication by verifying the Certificate and generating a Proof of Ownership from the server 0x02 M Yes communicationConfiguration NOT USED 0x00 M Yes lengthOfCertificateClient Length parameter for certificateClient uint16 M Yes certificateClient The Certificate to verify uint8[] M Yes lengthOfChallengeClient Length parameter for challengeClient uint16 M Yes challengeClient See 3.1.1.1 uint8[] M Yes AUTH_REQ 117 Upon reception of a verifyCertificateBidirectional request, the server shall determine whether the Authentication delay timer is currently running. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Authentication | Security capability: Authentication | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-DAI-001 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00893 | AUTH_REQ 118 If upon reception of verifyCertificateBidirectional request the Authentication delay timer is expired, the server shall continue to process the verifyCertificateBidirectional request.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-KEY-005 | High Proposal Ready Open point: OP-003 | DetailsFull requirement text AUTH_REQ 118 If upon reception of verifyCertificateBidirectional request the Authentication delay timer is expired, the server shall continue to process the verifyCertificateBidirectional request. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-003 Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-KEY-005 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling High, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00894 | AUTH_INFO 24 The column “Included in proofOfOwnershipServer”, present in several message-definition tables, indicates whether the corresponding field shall be covered by the proofOfOwnershipServer signature computed by the server and included in its response.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-DAI-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text AUTH_INFO 24 The column “Included in proofOfOwnershipServer”, present in several message-definition tables, indicates whether the corresponding field shall be covered by the proofOfOwnershipServer signature computed by the server and included in its response. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-DAI-004 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00895 | AUTH_REQ 45 If the server verifies the client certificate as valid, the server shall create the requested client authentication pending state.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Authentication | Feature / interface: Authentication Architecture: Security Services SSR: SSR-DAI-001 | High Proposal Ready Open point: OP-003 | DetailsFull requirement text AUTH_REQ 45 If the server verifies the client certificate as valid, the server shall create the requested client authentication pending state. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-003 Traceability Feature: Authentication | Security capability: Authentication | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-DAI-001 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00896 | Internal Page 9 (31) AUTH_REQ 119 If an authentication pending state already exists, the server shall replace the existing authentication pending state with the new one.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | High Proposal Ready Open point: - | DetailsFull requirement text Internal Page 9 (31) AUTH_REQ 119 If an authentication pending state already exists, the server shall replace the existing authentication pending state with the new one. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00897 | 3.1.1.1 challengeClient AUTH_REQ 3 This field shall consists of 32 octets.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-005 | Medium Proposal Ready Open point: - | DetailsFull requirement text 3.1.1.1 challengeClient AUTH_REQ 3 This field shall consists of 32 octets. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-005 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00898 | AUTH_REQ 4 The challengeClient (ISO 14229-1:2020) shall be generated using a CRNG.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-SYS-009 | Medium Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 4 The challengeClient (ISO 14229-1:2020) shall be generated using a CRNG. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-SYS-009 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00899 | 3.1.1.2 lengthOfCertificateClient AUTH_REQ 172 The expected range values of lengthOfCertificateClient shall be from 0x00C8 to 0x0800.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Accept with Assumption | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-KEY-004 | High Proposal Ready Open point: - | DetailsFull requirement text 3.1.1.2 lengthOfCertificateClient AUTH_REQ 172 The expected range values of lengthOfCertificateClient shall be from 0x00C8 to 0x0800. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-KEY-004 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling High, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00900 | AUTH_REQ 173 The server shall verify the value of lengthOfCertificateClient upon reception of verifyCertificateBidirectional request.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-KEY-005 | High Proposal Ready Open point: OP-003 | DetailsFull requirement text AUTH_REQ 173 The server shall verify the value of lengthOfCertificateClient upon reception of verifyCertificateBidirectional request. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-003 Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-KEY-005 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling High, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00901 | AUTH_REQ 174 If the lengthOfCertificateClient value is not within the expected range, the server shall send negative response code 0x13 (incorrectMessageLengthOrInvalidFormat).Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-KEY-005 | High Proposal Ready Open point: OP-003 | DetailsFull requirement text AUTH_REQ 174 If the lengthOfCertificateClient value is not within the expected range, the server shall send negative response code 0x13 (incorrectMessageLengthOrInvalidFormat). Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-003 Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-KEY-005 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling High, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00902 | 3.1.2 Response AUTH_REQ 5 The response for verifyCertificateBidirectional subfunction shall be formatted according to Table 6.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Accept with Assumption | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-KEY-004 | High Proposal Ready Open point: - | DetailsFull requirement text 3.1.2 Response AUTH_REQ 5 The response for verifyCertificateBidirectional subfunction shall be formatted according to Table 6. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-KEY-004 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling High, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00903 | AUTH_REQ 120 Upon positively responding, the server shall start the Authentication completion timer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | High Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 120 Upon positively responding, the server shall start the Authentication completion timer. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00904 | ephemeralPublicKeyServer See 3.1.2.3 uint8[] M Yes 3.1.2.1 challengeServer AUTH_REQ 6 The challengeServer field shall consists of 32 octets generated using a CRNG.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-006 | High Proposal Ready Open point: - | DetailsFull requirement text ephemeralPublicKeyServer See 3.1.2.3 uint8[] M Yes 3.1.2.1 challengeServer AUTH_REQ 6 The challengeServer field shall consists of 32 octets generated using a CRNG. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-006 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00905 | AUTH_REQ 7 The proof/signature shall be generated according to the pseudo code below.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DAI-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 7 The proof/signature shall be generated according to the pseudo code below. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DAI-002 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00906 | 3.1.3 Negative Response AUTH_REQ 121 If upon reception of verifyCertificateBidirectional request the Authentication delay timer is running, the server shall respond to the verifyCertificateBidirectional request with a Negative Response Code (NRC) 0x37, indicating requiredTimeDelayNotExpired.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-KEY-005 | High Proposal Ready Open point: OP-003 | DetailsFull requirement text 3.1.3 Negative Response AUTH_REQ 121 If upon reception of verifyCertificateBidirectional request the Authentication delay timer is running, the server shall respond to the verifyCertificateBidirectional request with a Negative Response Code (NRC) 0x37, indicating requiredTimeDelayNotExpired. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-003 Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-KEY-005 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling High, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00907 | AUTH_REQ 122 If the server verifies the client certificate as invalid, it shall respond to the verifyCertificateBidirectional request with a Negative Response Code (NRC) 0x10, indicating generalReject.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Authentication | Feature / interface: Authentication Architecture: Security Services SSR: SSR-DAI-001 | High Proposal Ready Open point: OP-003 | DetailsFull requirement text AUTH_REQ 122 If the server verifies the client certificate as invalid, it shall respond to the verifyCertificateBidirectional request with a Negative Response Code (NRC) 0x10, indicating generalReject. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-003 Traceability Feature: Authentication | Security capability: Authentication | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-DAI-001 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00908 | AUTH_REQ 123 If the server fails or cannot determine that the authentication pending state was stored, it shall respond to the verifyCertificateBidirectional request with a Negative Response Code (NRC) 0x94, indicating ResourceTemporarilyNotAvailable.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-KEY-005 | High Proposal Ready Open point: OP-003 | DetailsFull requirement text AUTH_REQ 123 If the server fails or cannot determine that the authentication pending state was stored, it shall respond to the verifyCertificateBidirectional request with a Negative Response Code (NRC) 0x94, indicating ResourceTemporarilyNotAvailable. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-003 Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-KEY-005 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling High, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00909 | Internal Page 12 (31) 3.2.1 Request AUTH_REQ 8 The request for proofOfOwnership subfunction shall be defined according to Table 7.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-006 | Medium Proposal Ready Open point: - | DetailsFull requirement text Internal Page 12 (31) 3.2.1 Request AUTH_REQ 8 The request for proofOfOwnership subfunction shall be defined according to Table 7. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-006 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00910 | Table 7 – proofOfOwnership Request Field Description Type/Value Cvt Included in proofOfOwnershipClient Authentication Request SID Service ID for 0x29 M Yes proofOfOwnership] Verify the Proof of Ownership from the client 0x03 M Yes lengthOfProofOfOwnershipClient This field indicates the length (in octets) of the proofOfOwnershipClient field proofOfOwnershipClient See 3.2.1.1 uint8[] M No lengthOfEphemeralPublicKey Client Length parameter for ephemeralPublicKey Client ephemeralPublicKeyClient See 3.2.1.2 uint16 M Yes AUTH_REQ 110 The server shall verify whether any existing authentication pending state corresponds to the client submitting the proofOfOwnership request.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-RBAC-004 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text Table 7 – proofOfOwnership Request Field Description Type/Value Cvt Included in proofOfOwnershipClient Authentication Request SID Service ID for 0x29 M Yes proofOfOwnership] Verify the Proof of Ownership from the client 0x03 M Yes lengthOfProofOfOwnershipClient This field indicates the length (in octets) of the proofOfOwnershipClient field proofOfOwnershipClient See 3.2.1.1 uint8[] M No lengthOfEphemeralPublicKey Client Length parameter for ephemeralPublicKey Client ephemeralPublicKeyClient See 3.2.1.2 uint16 M Yes AUTH_REQ 110 The server shall verify whether any existing authentication pending state corresponds to the client submitting the proofOfOwnership request. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-RBAC-004 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00911 | AUTH_REQ 111 If an existing authentication pending state is found, the server shall verify if the Authentication completion timer is currently running.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | High Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 111 If an existing authentication pending state is found, the server shall verify if the Authentication completion timer is currently running. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00912 | AUTH_REQ 112 If the Authentication completion timer is currently running, the server shall continue to process the client’s proofOfOwnership request.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | High Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 112 If the Authentication completion timer is currently running, the server shall continue to process the client’s proofOfOwnership request. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00913 | AUTH_REQ 113 If the client proofOfOwnership signature verification fails, the server shall delete the authentication pending state connected to the client submitting the proofOfOwnership request.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration; Security evidence and traceability / OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface SSR: SSR-DAI-004 | High Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 113 If the client proofOfOwnership signature verification fails, the server shall delete the authentication pending state connected to the client submitting the proofOfOwnership request. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Backend and IT Systems; OEM/Customer Review Interface | Work product: Requirement traceability record | SSR: SSR-DAI-004 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00914 | AUTH_REQ 114 If the server fails or cannot determine that the authentication state was stored, the server shall delete the authentication pending state connected to the client submitting the proofOfOwnership request.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-003 | High Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 114 If the server fails or cannot determine that the authentication state was stored, the server shall delete the authentication pending state connected to the client submitting the proofOfOwnership request. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-003 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00915 | AUTH_REQ 115 If the client’s proofOfOwnership signature is successfully verified, the server shall establish a new authentication state for the client.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-DAI-004 | High Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 115 If the client’s proofOfOwnership signature is successfully verified, the server shall establish a new authentication state for the client. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-DAI-004 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00916 | Internal Page 13 (31) If an active authentication state already exists, the server shall replace the existing state with the newly established one.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | High Proposal Ready Open point: - | DetailsFull requirement text Internal Page 13 (31) If an active authentication state already exists, the server shall replace the existing state with the newly established one. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 13 · page 13 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00917 | AUTH_REQ 160 The proofOfOwnershipClient shall be generated according to the pseudo code below.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-006 | Medium Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 160 The proofOfOwnershipClient shall be generated according to the pseudo code below. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-006 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 13 · page 13 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00918 | 3.2.2 Response AUTH_REQ 161 The response for proofOfOwnership subfunction shall be according to Table 8.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-006 | Medium Proposal Ready Open point: - | DetailsFull requirement text 3.2.2 Response AUTH_REQ 161 The response for proofOfOwnership subfunction shall be according to Table 8. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-006 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 13 · page 13 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00919 | AUTH_REQ 162 The signature shall be generated according to the pseudo code below.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DAI-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 162 The signature shall be generated according to the pseudo code below. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DAI-002 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 14 · page 14 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00920 | 3.2.3 Negative Response AUTH_REQ 124 If the server determines that the client does not have an existing authentication pending state, it shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x24, indicating requestSequenceError.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | High Proposal Ready Open point: - | DetailsFull requirement text 3.2.3 Negative Response AUTH_REQ 124 If the server determines that the client does not have an existing authentication pending state, it shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x24, indicating requestSequenceError. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 14 · page 14 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00921 | AUTH_REQ 125 If the server determines that the client have an existing authentication pending state and the Authentication completion timer is expired, the server shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x24, indicating requestSequenceError.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | High Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 125 If the server determines that the client have an existing authentication pending state and the Authentication completion timer is expired, the server shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x24, indicating requestSequenceError. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 14 · page 14 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00922 | AUTH_REQ 126 If the server cannot determine if the client does have an existing authentication pending state, it shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x94, indicating ResourceTemporarilyNotAvailable.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-003 | High Proposal Ready Open point: OP-004 | DetailsFull requirement text AUTH_REQ 126 If the server cannot determine if the client does have an existing authentication pending state, it shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x94, indicating ResourceTemporarilyNotAvailable. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-004 Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-003 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 14 · page 14 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00923 | AUTH_REQ 127 If the server is trying to delete the authentication pending state as consequence of the client proofOfOwnership signature verification failure, and the server determines that the authentication pending state was deleted, it shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x10, indicating generalReject.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration; Security evidence and traceability / OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface SSR: SSR-DAI-004 | High Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 127 If the server is trying to delete the authentication pending state as consequence of the client proofOfOwnership signature verification failure, and the server determines that the authentication pending state was deleted, it shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x10, indicating generalReject. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Backend and IT Systems; OEM/Customer Review Interface | Work product: Requirement traceability record | SSR: SSR-DAI-004 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 14 · page 14 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00924 | AUTH_REQ 128 If the server is trying to delete the authentication pending state as consequence of the client proofOfOwnership signature verification failure, and the server cannot determine that the authentication pending state was deleted, it shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x94, indicating ResourceTemporarilyNotAvailable.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration; Security evidence and traceability / OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface SSR: SSR-DAI-004 | High Proposal Ready Open point: OP-004 | DetailsFull requirement text AUTH_REQ 128 If the server is trying to delete the authentication pending state as consequence of the client proofOfOwnership signature verification failure, and the server cannot determine that the authentication pending state was deleted, it shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x94, indicating ResourceTemporarilyNotAvailable. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-004 Traceability Feature: Backend and IT integration; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Backend and IT Systems; OEM/Customer Review Interface | Work product: Requirement traceability record | SSR: SSR-DAI-004 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 14 · page 14 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00925 | AUTH_REQ 129 If the server is deleting the authentication pending state as consequence of failure to store the authentication state, it shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x94, indicating ResourceTemporarilyNotAvailable.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | High Proposal Ready Open point: OP-004 | DetailsFull requirement text AUTH_REQ 129 If the server is deleting the authentication pending state as consequence of failure to store the authentication state, it shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x94, indicating ResourceTemporarilyNotAvailable. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-004 Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 14 · page 14 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00926 | 3.3.1 Request AUTH_REQ 159 The request for deAuthenticate subfunction shall be formatted according to Table 9.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-006 | Medium Proposal Ready Open point: - | DetailsFull requirement text 3.3.1 Request AUTH_REQ 159 The request for deAuthenticate subfunction shall be formatted according to Table 9. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-006 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 15 · page 15 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00927 | Table 9 – deAuthenticate request message layout Field Description Type/Value Cvt Authentication Request SID Service ID for 0x29 M SubFunction = [AuthenticationTask = deAuthenticate] Subfunction for request to leave the authenticated state 0x00 M 3.3.2 Response AUTH_REQ 96 The response for deAuthenticate subfunction shall be formatted according to Table 10.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-RBAC-004 | High Proposal Ready Open point: - | DetailsFull requirement text Table 9 – deAuthenticate request message layout Field Description Type/Value Cvt Authentication Request SID Service ID for 0x29 M SubFunction = [AuthenticationTask = deAuthenticate] Subfunction for request to leave the authenticated state 0x00 M 3.3.2 Response AUTH_REQ 96 The response for deAuthenticate subfunction shall be formatted according to Table 10. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-RBAC-004 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 15 · page 15 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00928 | 0x00 – 0xFF M AUTH_REQ 158 The server shall delete/invalidate the client’s authentication prior to positively responding to the deAuthenticate request.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | High Proposal Ready Open point: - | DetailsFull requirement text 0x00 – 0xFF M AUTH_REQ 158 The server shall delete/invalidate the client’s authentication prior to positively responding to the deAuthenticate request. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 15 · page 15 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00929 | 3.3.3 Negative Response AUTH_REQ 130 If the server determines that the client is not currently authenticated, it shall respond to the deAuthenticate request with a Negative Response Code (NRC) 0x24, indicating a requestSequenceError.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text 3.3.3 Negative Response AUTH_REQ 130 If the server determines that the client is not currently authenticated, it shall respond to the deAuthenticate request with a Negative Response Code (NRC) 0x24, indicating a requestSequenceError. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 15 · page 15 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00930 | AUTH_REQ 131 If the server cannot determine that the client is currently authenticated, it shall respond to the deAuthenticate request with a Negative Response Code (NRC) 0x94, indicating a ResourceTemporarilyNotAvailable.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-003 | Medium Proposal Ready Open point: OP-004 | DetailsFull requirement text AUTH_REQ 131 If the server cannot determine that the client is currently authenticated, it shall respond to the deAuthenticate request with a Negative Response Code (NRC) 0x94, indicating a ResourceTemporarilyNotAvailable. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-004 Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-003 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 15 · page 15 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00931 | Internal Page 16 (31) AUTH_REQ 132 If the server is unable to delete the client's authentication state or cannot verify its presence, it shall respond to the deAuthenticate request with Negative Response Code (NRC) 0x94, indicating ResourceTemporarilyNotAvailable.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-003 | High Proposal Ready Open point: OP-004 | DetailsFull requirement text Internal Page 16 (31) AUTH_REQ 132 If the server is unable to delete the client's authentication state or cannot verify its presence, it shall respond to the deAuthenticate request with Negative Response Code (NRC) 0x94, indicating ResourceTemporarilyNotAvailable. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-004 Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-003 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 16 · page 16 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00932 | AUTH_INFO 133 If the server is unable to delete the client’s authentication state or cannot retrieve it due to internal errors, the server responds NRC 0x94.This informs the client that the authentication state may still exist on the server.Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | High Proposal Ready Open point: - | DetailsFull requirement text AUTH_INFO 133 If the server is unable to delete the client’s authentication state or cannot retrieve it due to internal errors, the server responds NRC 0x94.This informs the client that the authentication state may still exist on the server. Engineering expectation Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Non-functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: Requirement traceability record | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 16 · page 16 Estimation / resource / tool / IT / hardware impact Effort High, Competence Low, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00933 | 4 General 4.1 Certificate AUTH_REQ 175 The signature algorithm used throughout the authentication process shall be ED25519.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Accept with Assumption | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Validate assumption with customer; complete mapping; implement. | Authentication | Feature / interface: Authentication Architecture: Security Services SSR: SSR-DAI-001 | High Proposal Ready Open point: - | DetailsFull requirement text 4 General 4.1 Certificate AUTH_REQ 175 The signature algorithm used throughout the authentication process shall be ED25519. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Authentication | Security capability: Authentication | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-DAI-001 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 16 · page 16 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00934 | AUTH_REQ 176 The client shall use the private key corresponding to the client certificate to generate the signatures.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Accept with Assumption | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Validate assumption with customer; complete mapping; implement. | Authentication | Feature / interface: Authentication Architecture: Security Services SSR: SSR-DAI-001 | High Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 176 The client shall use the private key corresponding to the client certificate to generate the signatures. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Authentication | Security capability: Authentication | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-DAI-001 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 16 · page 16 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00935 | AUTH_REQ 177 The server shall use the private key corresponding to the server certificate to generate the signatures.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Authentication | Feature / interface: Authentication Architecture: Security Services SSR: SSR-DAI-001 | High Proposal Ready Open point: OP-003 | DetailsFull requirement text AUTH_REQ 177 The server shall use the private key corresponding to the server certificate to generate the signatures. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-003 Traceability Feature: Authentication | Security capability: Authentication | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-DAI-001 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 16 · page 16 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00936 | AUTH_REQ 163 The format and the structure of the certificates shall be based on (CVS30).Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Accept with Assumption | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-KEY-004 | High Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 163 The format and the structure of the certificates shall be based on (CVS30). Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-KEY-004 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 16 · page 16 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling High, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00937 | AUTH_REQ 164 The server shall reject a received client’s certificate, sent using the verifyCertificateBidirectional subFunction, if it matches the server’s own certificate.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Authentication | Feature / interface: Authentication Architecture: Security Services SSR: SSR-DAI-001 | High Proposal Ready Open point: OP-003 | DetailsFull requirement text AUTH_REQ 164 The server shall reject a received client’s certificate, sent using the verifyCertificateBidirectional subFunction, if it matches the server’s own certificate. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-003 Traceability Feature: Authentication | Security capability: Authentication | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-DAI-001 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 16 · page 16 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00938 | AUTH_INFO 7 It should not be possible to “unlock” the server using its own key/certificate.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Authentication | Feature / interface: Authentication Architecture: Security Services SSR: SSR-DAI-001 | High Proposal Ready Open point: OP-003 | DetailsFull requirement text AUTH_INFO 7 It should not be possible to “unlock” the server using its own key/certificate. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-003 Traceability Feature: Authentication | Security capability: Authentication | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-DAI-001 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 16 · page 16 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00939 | AUTH_REQ 165 The server shall verify the client certificate, sent using the verifyCertificateBidirectional subFunction, according to Figure 3.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Authentication | Feature / interface: Authentication Architecture: Security Services SSR: SSR-DAI-001 | High Proposal Ready Open point: OP-003 | DetailsFull requirement text AUTH_REQ 165 The server shall verify the client certificate, sent using the verifyCertificateBidirectional subFunction, according to Figure 3. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-003 Traceability Feature: Authentication | Security capability: Authentication | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-DAI-001 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 16 · page 16 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00940 | AUTH_REQ 134 The server shall verify the Signature of the Client certificate using the AUTH-CA EMP entity public key.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Authentication | Feature / interface: Authentication Architecture: Security Services SSR: SSR-DAI-001 | High Proposal Ready Open point: OP-003 | DetailsFull requirement text AUTH_REQ 134 The server shall verify the Signature of the Client certificate using the AUTH-CA EMP entity public key. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-003 Traceability Feature: Authentication | Security capability: Authentication | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-DAI-001 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 16 · page 16 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00941 | Internal Page 18 (31) 4.1.1 NodeUID extension If the NodeUID extension is detected, the server shall: AUTH_REQ 166 • Check if the NodeUID of the server is present in the NodeUIDs extension.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text Internal Page 18 (31) 4.1.1 NodeUID extension If the NodeUID extension is detected, the server shall: AUTH_REQ 166 • Check if the NodeUID of the server is present in the NodeUIDs extension. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 18 · page 18 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00942 | AUTH_REQ 9 • If the server NodeUID is not found in the NodeUID extension, the server shall reject the certificate and generate NRC 0x10 (generalReject).Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Authentication | Feature / interface: Authentication Architecture: Security Services SSR: SSR-DAI-001 | High Proposal Ready Open point: OP-003 | DetailsFull requirement text AUTH_REQ 9 • If the server NodeUID is not found in the NodeUID extension, the server shall reject the certificate and generate NRC 0x10 (generalReject). Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-003 Traceability Feature: Authentication | Security capability: Authentication | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-DAI-001 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 18 · page 18 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00943 | AUTH_REQ 106 If the NodeUID extension is not detected, the operation shall continue as in AUTH_INFO 25 A certificate without NodeUID extension implies that the certificate is applicable for any NodeUID.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Accept with Assumption | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Validate assumption with customer; complete mapping; implement. | Authentication | Feature / interface: Authentication Architecture: Security Services SSR: SSR-DAI-001 | High Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 106 If the NodeUID extension is not detected, the operation shall continue as in AUTH_INFO 25 A certificate without NodeUID extension implies that the certificate is applicable for any NodeUID. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Authentication | Security capability: Authentication | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-DAI-001 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 18 · page 18 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00944 | 4.1.2 ECU-Diagnostic Role extension AUTH_REQ 170 The ECU-Diagnostic role extension shall be included in the client certificate.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Validate assumption with customer; complete mapping; implement. | Authentication | Feature / interface: Authentication Architecture: Security Services SSR: SSR-RBAC-002 | High Proposal Ready Open point: - | DetailsFull requirement text 4.1.2 ECU-Diagnostic Role extension AUTH_REQ 170 The ECU-Diagnostic role extension shall be included in the client certificate. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Authentication | Security capability: Authentication | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-002 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 18 · page 18 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00945 | AUTH_REQ 13 The roles shall correspond to a bit pattern-octet string.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-006 | Medium Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 13 The roles shall correspond to a bit pattern-octet string. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-006 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 18 · page 18 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00946 | AUTH_INFO 8 The interpretation of the roles should follow as the example below: • Role 1 -> 0000 0000 0000 0000 0000 0000 0000 0001 – 00 00 00 01 • Role 32 -> 1000 0000 0000 0000 0000 0000 0000 0000 – 80 00 00 00 • Role 2 and 4 -> 0000 0000 0000 0000 0000 0000 0000 1010 – 00 00 00 0A.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-006 | Low Proposal Ready Open point: - | DetailsFull requirement text AUTH_INFO 8 The interpretation of the roles should follow as the example below: • Role 1 -> 0000 0000 0000 0000 0000 0000 0000 0001 – 00 00 00 01 • Role 32 -> 1000 0000 0000 0000 0000 0000 0000 0000 – 80 00 00 00 • Role 2 and 4 -> 0000 0000 0000 0000 0000 0000 0000 1010 – 00 00 00 0A. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-006 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 18 · page 18 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00947 | While the ECU-Diagnostic Role extension specifies the roles assigned to a client, the D-RBACC extension may both grant additional permissions and restrict permissions beyond those derived from the client’s roles.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | High Proposal Ready Open point: - | DetailsFull requirement text While the ECU-Diagnostic Role extension specifies the roles assigned to a client, the D-RBACC extension may both grant additional permissions and restrict permissions beyond those derived from the client’s roles. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Cybersecurity control (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 18 · page 18 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00948 | AUTH_REQ 14 If D-RBACC extension is detected, the server shall overrule the RBACC with the D-RBACC permissions.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 14 If D-RBACC extension is detected, the server shall overrule the RBACC with the D-RBACC permissions. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 18 · page 18 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00949 | AUTH_INFO 61 This means that if D-RBACC logic denies/permits certain access, the server shall deny/permit the access regardless of what RBACC logic permits/denies.Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-RBAC-004 | Medium Proposal Ready Open point: - | DetailsFull requirement text AUTH_INFO 61 This means that if D-RBACC logic denies/permits certain access, the server shall deny/permit the access regardless of what RBACC logic permits/denies. Engineering expectation Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-RBAC-004 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 18 · page 18 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00950 | Internal Page 19 (31) As part of the certificate verification: AUTH_REQ 135 • The server shall validate the D-RBACC by parsing all its content.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Authentication | Feature / interface: Authentication; Security evidence and traceability / OEM/Customer Review Interface Architecture: Security Services; OEM/Customer Review Interface SSR: SSR-DAI-001 | High Proposal Ready Open point: OP-003 | DetailsFull requirement text Internal Page 19 (31) As part of the certificate verification: AUTH_REQ 135 • The server shall validate the D-RBACC by parsing all its content. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-003 Traceability Feature: Authentication; Security evidence and traceability | Security capability: Authentication | Interface: OEM/Customer Review Interface | Architecture: Security Services; OEM/Customer Review Interface | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-DAI-001 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 19 · page 19 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00951 | If content is invalid, the certificate is invalid and the server shall return a Negative Response Code (NRC) 0x10, indicating generalReject.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Certificate handling | Feature / interface: Certificate handling Architecture: Security Services SSR: SSR-KEY-002 | High Proposal Ready Open point: OP-003 | DetailsFull requirement text If content is invalid, the certificate is invalid and the server shall return a Negative Response Code (NRC) 0x10, indicating generalReject. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-003 Traceability Feature: Certificate handling | Security capability: Certificate handling | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-KEY-002 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 19 · page 19 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00952 | AUTH_REQ 136 • The server shall verify that the D-RBACC version provided by the client is compatible with the server’s supported D-RBACC version.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-RBAC-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 136 • The server shall verify that the D-RBACC version provided by the client is compatible with the server’s supported D-RBACC version. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-RBAC-003 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 19 · page 19 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00953 | If non-compliant, the certificate is invalid and the server shall return a Negative Response Code (NRC) 0x10, indicating generalReject.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Certificate handling | Feature / interface: Certificate handling Architecture: Security Services SSR: SSR-KEY-002 | High Proposal Ready Open point: OP-003 | DetailsFull requirement text If non-compliant, the certificate is invalid and the server shall return a Negative Response Code (NRC) 0x10, indicating generalReject. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-003 Traceability Feature: Certificate handling | Security capability: Certificate handling | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-KEY-002 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 19 · page 19 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00954 | 4.1.4 basicContraints extension AUTH_REQ 42 The basicConstraints extension CA field shall be False.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-006 | Low Proposal Ready Open point: - | DetailsFull requirement text 4.1.4 basicContraints extension AUTH_REQ 42 The basicConstraints extension CA field shall be False. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-006 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 19 · page 19 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00955 | 4.1.5 Key Usage extension AUTH_REQ 15 The Key Usage extension (RFC 5280) shall be included in the client certificate.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Accept with Assumption | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Validate assumption with customer; complete mapping; implement. | Authentication | Feature / interface: Authentication Architecture: Security Services SSR: SSR-DAI-001 | High Proposal Ready Open point: - | DetailsFull requirement text 4.1.5 Key Usage extension AUTH_REQ 15 The Key Usage extension (RFC 5280) shall be included in the client certificate. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Authentication | Security capability: Authentication | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-DAI-001 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 19 · page 19 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00956 | AUTH_REQ 47 The Key Usage extension shall contain DigitalSignature.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | Authentication | Feature / interface: Authentication Architecture: Security Services SSR: SSR-DAI-001 | High Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 47 The Key Usage extension shall contain DigitalSignature. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Authentication | Security capability: Authentication | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-DAI-001 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 19 · page 19 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00957 | 4.1.6 Extended Key Usage extension AUTH_REQ 95 The Extended Key Usage extension (RFC 5280) shall be included in the client certificate.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Accept with Assumption | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Validate assumption with customer; complete mapping; implement. | Authentication | Feature / interface: Authentication Architecture: Security Services SSR: SSR-DAI-001 | High Proposal Ready Open point: - | DetailsFull requirement text 4.1.6 Extended Key Usage extension AUTH_REQ 95 The Extended Key Usage extension (RFC 5280) shall be included in the client certificate. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Authentication | Security capability: Authentication | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-DAI-001 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 19 · page 19 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00958 | AUTH_REQ 107 The extension ExtendedKeyUsage shall contain clientAuth (1.3.6.1.5.5.7.3.2).Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-006 | High Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 107 The extension ExtendedKeyUsage shall contain clientAuth (1.3.6.1.5.5.7.3.2). Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-006 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 19 · page 19 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00959 | 4.1.7 SignatureAlgorithm AUTH_REQ 105 The extension SignatureAlgorithm shall contain ED25519 (1.3.101.112).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-DAI-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text 4.1.7 SignatureAlgorithm AUTH_REQ 105 The extension SignatureAlgorithm shall contain ED25519 (1.3.101.112). Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-DAI-002 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 19 · page 19 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00960 | 4.1.8 Certificate Validity Time AUTH_REQ 169 The server shall validate the certificate so that: 𝑛𝑜𝑡𝐵𝑒𝑓𝑜𝑟𝑒 ≤ 𝐶𝑒𝑟𝑡𝑖𝑓𝑖𝑐𝑎𝑡𝑒-𝑡𝑖𝑚𝑒 ≤ 𝑛𝑜𝑡𝐴𝑓𝑡𝑒𝑟 AUTH_INFO 137 The notBefore and notAfter are received as fields in the certificate while Certificate-Time is the EMP entity defined in CVS34.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Authentication | Feature / interface: Authentication Architecture: Security Services SSR: SSR-DAI-001 | High Proposal Ready Open point: OP-003 | DetailsFull requirement text 4.1.8 Certificate Validity Time AUTH_REQ 169 The server shall validate the certificate so that: 𝑛𝑜𝑡𝐵𝑒𝑓𝑜𝑟𝑒 ≤ 𝐶𝑒𝑟𝑡𝑖𝑓𝑖𝑐𝑎𝑡𝑒-𝑡𝑖𝑚𝑒 ≤ 𝑛𝑜𝑡𝐴𝑓𝑡𝑒𝑟 AUTH_INFO 137 The notBefore and notAfter are received as fields in the certificate while Certificate-Time is the EMP entity defined in CVS34. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-003 Traceability Feature: Authentication | Security capability: Authentication | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-DAI-001 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 19 · page 19 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00961 | Internal Page 20 (31) 4.2 State-keeping The server shall invalidate the authentication pending state in the event of: AUTH_REQ 138 • The server is reset (i.e server is power cycled).Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | High Proposal Ready Open point: - | DetailsFull requirement text Internal Page 20 (31) 4.2 State-keeping The server shall invalidate the authentication pending state in the event of: AUTH_REQ 138 • The server is reset (i.e server is power cycled). Engineering expectation Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 20 · page 20 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00962 | AUTH_REQ 156 If a server reset is triggered by a client request (e.g., UDS service 0x11), the server shall send the corresponding response before invalidating the authentication pending state.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text AUTH_REQ 156 If a server reset is triggered by a client request (e.g., UDS service 0x11), the server shall send the corresponding response before invalidating the authentication pending state. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 20 · page 20 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00963 | If a client and server have successfully completed the authentication process, the server shall invalidate the authentication state in the event of: AUTH_REQ 16 • The server is reset (i.e server is power cycled).Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | High Proposal Ready Open point: - | DetailsFull requirement text If a client and server have successfully completed the authentication process, the server shall invalidate the authentication state in the event of: AUTH_REQ 16 • The server is reset (i.e server is power cycled). Engineering expectation Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 20 · page 20 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00964 | AUTH_REQ 157 If a server reset is triggered by a client request (e.g., UDS service 0x11), the server shall send the corresponding response before invalidating the authentication state.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-DIAG-004 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text AUTH_REQ 157 If a server reset is triggered by a client request (e.g., UDS service 0x11), the server shall send the corresponding response before invalidating the authentication state. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-DIAG-004 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 20 · page 20 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00965 | The server’s authentication pending state shall contain the minimum of (non-exhaustive list): AUTH_REQ 140 • Client address that issued the authentication request.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | High Proposal Ready Open point: - | DetailsFull requirement text The server’s authentication pending state shall contain the minimum of (non-exhaustive list): AUTH_REQ 140 • Client address that issued the authentication request. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 20 · page 20 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00966 | The server’s authentication state shall contain the minimum of (non-exhaustive list): AUTH_REQ 21 • SessionKey.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-002 | High Proposal Ready Open point: - | DetailsFull requirement text The server’s authentication state shall contain the minimum of (non-exhaustive list): AUTH_REQ 21 • SessionKey. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-002 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 21 · page 21 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00967 | AUTH_REQ 147 • Client roles (ECU diagnostic Role extension in client’s certificate) AUTH_REQ 148 • Client D-RBACC, if provided in the client’s certificate AUTH_REQ 149 The server shall support only one authentication state.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Authentication | Feature / interface: Authentication Architecture: Security Services SSR: SSR-RBAC-002 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text AUTH_REQ 147 • Client roles (ECU diagnostic Role extension in client’s certificate) AUTH_REQ 148 • Client D-RBACC, if provided in the client’s certificate AUTH_REQ 149 The server shall support only one authentication state. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Authentication | Security capability: Authentication | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-002 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 21 · page 21 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00968 | AUTH_REQ 150 The server shall support only one authentication pending state.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-003 | High Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 150 The server shall support only one authentication pending state. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-003 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 21 · page 21 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00969 | AUTH_REQ 167 The private keys shall be generated using a CRNG.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-KEY-004 | High Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 167 The private keys shall be generated using a CRNG. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-KEY-004 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 22 · page 22 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00970 | AUTH_REQ 168 The sessionKey shall be generated according to the pseudo code below.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-006 | High Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 168 The sessionKey shall be generated according to the pseudo code below. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-006 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 22 · page 22 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00971 | AUTH_REQ 24 The server shall ensure that the sessionKey is exclusively used for the application responsible for communication over securedDataTransmission (CVS32).Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-008 | High Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 24 The server shall ensure that the sessionKey is exclusively used for the application responsible for communication over securedDataTransmission (CVS32). Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-008 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 22 · page 22 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00972 | 4.5 CRNG AUTH_REQ 33 Solution for a CRNG shall be according to (CVS150).Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-006 | Medium Proposal Ready Open point: - | DetailsFull requirement text 4.5 CRNG AUTH_REQ 33 Solution for a CRNG shall be according to (CVS150). Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-006 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 22 · page 22 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00973 | Internal Page 23 (31) 4.6 Role Based Access Control AUTH_REQ 25 The server shall always allow the Authentication 0x29 service (ISO 14229-1:2020) regardless of the RBAC logic (CVS151).Expectation: Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. | Partially Accept | Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-RBAC-004 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text Internal Page 23 (31) 4.6 Role Based Access Control AUTH_REQ 25 The server shall always allow the Authentication 0x29 service (ISO 14229-1:2020) regardless of the RBAC logic (CVS151). Engineering expectation Security-relevant events are expected to be recorded with enough integrity and context to support evidence, diagnostics, and incident handling. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-RBAC-004 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 23 · page 23 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00974 | AUTH_REQ 109 Only Passive time-based de-authentication shall be supported.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-006 | High Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 109 Only Passive time-based de-authentication shall be supported. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-006 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 23 · page 23 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00975 | 4.7.1 TimeBasedPassiveDeAuthentication AUTH_REQ 26 The server shall start the timer (A3) after a valid proofOfOwnership has been received.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-003 | High Proposal Ready Open point: - | DetailsFull requirement text 4.7.1 TimeBasedPassiveDeAuthentication AUTH_REQ 26 The server shall start the timer (A3) after a valid proofOfOwnership has been received. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-003 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 23 · page 23 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00976 | AUTH_REQ 27 The server shall restart the timer (A3) every time a request is received by the same client.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-003 | Medium Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 27 The server shall restart the timer (A3) every time a request is received by the same client. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-003 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 23 · page 23 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00977 | AUTH_REQ 28 If the A3 timer timeouts before a new request is received (from the same client), the server shall invalidate the authentication state.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-003 | High Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 28 If the A3 timer timeouts before a new request is received (from the same client), the server shall invalidate the authentication state. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-003 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 23 · page 23 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00978 | AUTH_REQ 29 The parameter for passive timeout based deAuthenticate shall be decided in the project.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-006 | Medium Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 29 The parameter for passive timeout based deAuthenticate shall be decided in the project. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-006 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 23 · page 23 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00979 | AUTH_INFO 14 The A3 timer differs from S3 timer in terms of expected behavior during timeout and should not be implemented as a single timer.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Needs Internal Review | Needs internal review. Confirm whether this should-level requirement is in the committed baseline.Decision: Complete internal review of wording and baseline scope. | None | Feature / interface: System behavior Architecture: System Core SSR: None | Low Reviewed Internally Open point: - | DetailsFull requirement text AUTH_INFO 14 The A3 timer differs from S3 timer in terms of expected behavior during timeout and should not be implemented as a single timer. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Needs internal review. Confirm whether this should-level requirement is in the committed baseline. Rationale Non-mandatory wording; baseline inclusion not yet confirmed. Implementation approach Decide baseline inclusion internally, then issue an Accept/Partial position. Acceptance condition Internal baseline decision recorded. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 23 · page 23 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Complete internal review of wording and baseline scope. |
| REQ-AUTO-00980 | Internal Page 24 (31) 4.8 Authentication delay timer AUTH_INFO 38 The delay timer represents the required minimum time between verifyCertificateBidirectional request attempts.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Accept with Assumption | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-KEY-004 | High Proposal Ready Open point: - | DetailsFull requirement text Internal Page 24 (31) 4.8 Authentication delay timer AUTH_INFO 38 The delay timer represents the required minimum time between verifyCertificateBidirectional request attempts. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-KEY-004 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 24 · page 24 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling High, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00981 | AUTH_REQ 133 The delay timer shall be set to 1 second.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-006 | Medium Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 133 The delay timer shall be set to 1 second. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-006 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 24 · page 24 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00982 | AUTH_REQ 151 If the delay timer is not running, the server shall start it as part of verifyCertificateBidirectional request.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-KEY-005 | High Proposal Ready Open point: OP-003 | DetailsFull requirement text AUTH_REQ 151 If the delay timer is not running, the server shall start it as part of verifyCertificateBidirectional request. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-003 Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-KEY-005 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 24 · page 24 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling High, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00983 | AUTH_REQ 152 If the server can determine that a delay is not running after reset, it shall accept a subsequent authentication request without any delay.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-003 | High Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 152 If the server can determine that a delay is not running after reset, it shall accept a subsequent authentication request without any delay. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-003 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 24 · page 24 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00984 | AUTH_REQ 153 If the server cannot determine that a delay is not running after reset, it shall not accept a subsequent authentication request without any delay.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Partially Accept | Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-003 | High Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 153 If the server cannot determine that a delay is not running after reset, it shall not accept a subsequent authentication request without any delay. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-003 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 24 · page 24 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00985 | AUTH_REQ 154 The Authentication completion timer shall be set to 1 minute.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-006 | High Proposal Ready Open point: - | DetailsFull requirement text AUTH_REQ 154 The Authentication completion timer shall be set to 1 minute. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-006 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 24 · page 24 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00986 | Internal Page 29 (31) Annex B (informative) Change history Release Date Changes The whole standard has been reworked and shall be read in its entirety.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-006 | Medium Proposal Ready Open point: - | DetailsFull requirement text Internal Page 29 (31) Annex B (informative) Change history Release Date Changes The whole standard has been reworked and shall be read in its entirety. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-006 Source PDF Source evidence converted/markdown-cleaned/CVS31.md · CVS31 > Page 29 · page 29 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00987 | The User shall apply the latest version of this CVS32.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: System Core SSR: SSR-SYS-006 | Medium Proposal Ready Open point: - | DetailsFull requirement text The User shall apply the latest version of this CVS32. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 1 · page 1 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00988 | Internal Page 2 (29) Foreword This CVS32 contains requirement specification for TRATON GROUP and may be used by all within TRATON Group, if applicable.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | Low Proposal Ready Open point: - | DetailsFull requirement text Internal Page 2 (29) Foreword This CVS32 contains requirement specification for TRATON GROUP and may be used by all within TRATON Group, if applicable. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 2 · page 2 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Misinterpreted requirement could drive wrong design and late change cost. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00989 | Any review of CVS32 shall only be done in agreement with the involved departments stated in the table on the first page under section “Technical responsibility”.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: System behavior Architecture: Compliance Process SSR: SSR-SYS-009 | Low Proposal Ready Open point: - | DetailsFull requirement text Any review of CVS32 shall only be done in agreement with the involved departments stated in the table on the first page under section “Technical responsibility”. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior | Security capability: None | Interface: None | Architecture: Compliance Process | Work product: DIA / cybersecurity case | SSR: SSR-SYS-009 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 2 · page 2 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00990 | • Affiliate means any legal entity that directly or indirectly controls, is controlled by, or is commonly controlled with TRATON SE, it is being understood that “control” shall mean ownership of at least 50% of the voting rights or interest in the issued share capital, including for the avoidance of doubt any branch.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-TOOL-003 | Low Proposal Ready Open point: - | DetailsFull requirement text • Affiliate means any legal entity that directly or indirectly controls, is controlled by, or is commonly controlled with TRATON SE, it is being understood that “control” shall mean ownership of at least 50% of the voting rights or interest in the issued share capital, including for the avoidance of doubt any branch. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-TOOL-003 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 2 · page 2 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00991 | The keywords “shall”, “should”, “must” and so forth are used in this document and are to be interpreted in accordance with “Key words for use in RFCs to Indicate Requirement Levels” [10].Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | Key management | Feature / interface: Key management Architecture: Security Services SSR: SSR-KEY-001 | High Proposal Ready Open point: - | DetailsFull requirement text The keywords “shall”, “should”, “must” and so forth are used in this document and are to be interpreted in accordance with “Key words for use in RFCs to Indicate Requirement Levels” [10]. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Key management | Security capability: Key management | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-KEY-001 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 4 · page 4 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00992 | Internal Page 6 (29) 2 General SDT_REQ 1 The implementation of SDT (SecuredDataTransmission) shall follow the information provided in ISO14229-1 [1] chapter 16: Security sub-layer and in the TRATON Specification on Unified diagnostic Services (UDS) requirements [8].Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Accept with Assumption | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Validate assumption with customer; complete mapping; implement. | Diagnostic security | Feature / interface: Secure communication and freshness protection; Diagnostic security Architecture: Security Services SSR: SSR-RBAC-007 | High Proposal Ready Open point: - | DetailsFull requirement text Internal Page 6 (29) 2 General SDT_REQ 1 The implementation of SDT (SecuredDataTransmission) shall follow the information provided in ISO14229-1 [1] chapter 16: Security sub-layer and in the TRATON Specification on Unified diagnostic Services (UDS) requirements [8]. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Secure communication and freshness protection; Diagnostic security | Security capability: Diagnostic security | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-007 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00993 | SDT_REQ 2 Whenever a requirement in this document deviates from requirements in ISO14229-1 [1] the requirements of this document shall take precedence.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Secure communication and freshness protection Architecture: System Core SSR: SSR-SYS-006 | Medium Proposal Ready Open point: - | DetailsFull requirement text SDT_REQ 2 Whenever a requirement in this document deviates from requirements in ISO14229-1 [1] the requirements of this document shall take precedence. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Secure communication and freshness protection | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00994 | one diagnostic server in the boot-loader and one in the application, shall support SDT in all execution states.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Diagnostic security | Feature / interface: Secure communication and freshness protection; Diagnostic security Architecture: Security Services SSR: SSR-RBAC-007 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text one diagnostic server in the boot-loader and one in the application, shall support SDT in all execution states. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Secure communication and freshness protection; Diagnostic security | Security capability: Diagnostic security | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-007 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Medium, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00995 | SDT_REQ 4 The SDT server shall use the diagnostic tester address of the SDT client to identify the authentication state and hence the SecuredDataTransmissionKey.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Partially Accept | Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Authentication | Feature / interface: Secure communication and freshness protection; Authentication Architecture: Security Services SSR: SSR-RBAC-007 | High Proposal Ready Open point: OP-002 | DetailsFull requirement text SDT_REQ 4 The SDT server shall use the diagnostic tester address of the SDT client to identify the authentication state and hence the SecuredDataTransmissionKey. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-002 Traceability Feature: Secure communication and freshness protection; Authentication | Security capability: Authentication | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-RBAC-007 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00996 | (There may be more than one authentication state).Expectation: Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: None Architecture: None SSR: None | High Proposal Ready Open point: - | DetailsFull requirement text (There may be more than one authentication state). Engineering expectation Engineering expectation is unclear from the current evidence and needs customer clarification before baseline closure. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: None | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 6 · page 6 Estimation / resource / tool / IT / hardware impact Effort High, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-00997 | SDT_REQ 5 The server shall not allow an SDT message with service 0x84 as the application layer service (service 0x84 encapsulated inside another service 0x84).Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Application software behavior; Secure communication and freshness protection Architecture: Application Software SSR: SSR-SYS-008 | Low Proposal Ready Open point: OP-005 | DetailsFull requirement text SDT_REQ 5 The server shall not allow an SDT message with service 0x84 as the application layer service (service 0x84 encapsulated inside another service 0x84). Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Application software behavior; Secure communication and freshness protection | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-008 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 7 · page 7 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00998 | The server shall respond with application layer NRC 0x39, i.e.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept | Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria.Decision: Confirm responsibility allocation, then implement and verify. | None | Feature / interface: Application software behavior Architecture: Application Software SSR: SSR-SYS-008 | Medium Proposal Ready Open point: - | DetailsFull requirement text The server shall respond with application layer NRC 0x39, i.e. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. Rationale Binding, non-security requirement with feature/architecture traceability. Implementation approach Implement against the mapped feature/architecture element and verify per the test plan. Acceptance condition Customer confirms responsibility allocation and implementation method. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-008 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 7 · page 7 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Confirm responsibility allocation, then implement and verify. |
| REQ-AUTO-00999 | the response shall be a properly formatted SDT positive 3 ISO 14299-1:2020 Clarifications and Deviations 3.1 Anti-replay Protection and Transaction Coherency SDT_INFO 5 Anti-replay protection for SDT messages is provided by the ANTIREPLAYCNT protocol element.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces; Secure communication and freshness protection / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text the response shall be a properly formatted SDT positive 3 ISO 14299-1:2020 Clarifications and Deviations 3.1 Anti-replay Protection and Transaction Coherency SDT_INFO 5 Anti-replay protection for SDT messages is provided by the ANTIREPLAYCNT protocol element. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces; Secure communication and freshness protection | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 7 · page 7 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01000 | SDT_REQ 6 Both client and server shall maintain instances of the state variables PREQARC and PRESARC.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Secure communication and freshness protection; Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-006 | Medium Proposal Ready Open point: OP-005 | DetailsFull requirement text SDT_REQ 6 Both client and server shall maintain instances of the state variables PREQARC and PRESARC. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 7 · page 7 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01001 | SDT_REQ 7 At construction of an SDT request, the client shall increment PREQARC by one (1) and populate the ANTIREPLAYCNT protocol element with the resulting value.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces; Secure communication and freshness protection / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text SDT_REQ 7 At construction of an SDT request, the client shall increment PREQARC by one (1) and populate the ANTIREPLAYCNT protocol element with the resulting value. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces; Secure communication and freshness protection | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 7 · page 7 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01002 | SDT_REQ 8 At reception of an SDT request, the server shall verify that the value of the ANTIREPLAYCNT protocol element is greater than PREQARC, and if the message can be otherwise verified, update PREQARC to reflect the new value, i.e.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Secure communication and freshness protection; Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-006 | High Proposal Ready Open point: OP-005 | DetailsFull requirement text SDT_REQ 8 At reception of an SDT request, the server shall verify that the value of the ANTIREPLAYCNT protocol element is greater than PREQARC, and if the message can be otherwise verified, update PREQARC to reflect the new value, i.e. Engineering expectation Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 7 · page 7 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01003 | SDT_REQ 9 At construction of an SDT response, the server shall increment PRESARC by one (1) and populate the ANTIREPLAYCNT protocol element with the resulting value.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Secure communication and freshness protection; Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-006 | Medium Proposal Ready Open point: OP-005 | DetailsFull requirement text SDT_REQ 9 At construction of an SDT response, the server shall increment PRESARC by one (1) and populate the ANTIREPLAYCNT protocol element with the resulting value. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 7 · page 7 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01004 | SDT_REQ 10 At reception of an SDT response, the client shall verify that the value of the ANTIREPLAYCNT protocol element is greater than PRESARC, and if the message can be otherwise verified, update PRESARC to reflect the new value, i.e.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces; Secure communication and freshness protection / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | High Proposal Ready Open point: - | DetailsFull requirement text SDT_REQ 10 At reception of an SDT response, the client shall verify that the value of the ANTIREPLAYCNT protocol element is greater than PRESARC, and if the message can be otherwise verified, update PRESARC to reflect the new value, i.e. Engineering expectation Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces; Secure communication and freshness protection | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 7 · page 7 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01005 | Internal Page 8 (29) SDT_REQ 11 The client should populate the ANTIREPLAYCNT protocol element of the first request of an SDT sequence with the value zero (0), and set PREQARC accordingly.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces; Secure communication and freshness protection / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Low Proposal Ready Open point: - | DetailsFull requirement text Internal Page 8 (29) SDT_REQ 11 The client should populate the ANTIREPLAYCNT protocol element of the first request of an SDT sequence with the value zero (0), and set PREQARC accordingly. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces; Secure communication and freshness protection | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01006 | SDT_REQ 12 The server should populate the ANTIREPLAYCNT protocol element of the first response of an SDT sequence with the value zero (0), and set PRESARC accordingly.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Secure communication and freshness protection; Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-006 | Low Proposal Ready Open point: OP-005 | DetailsFull requirement text SDT_REQ 12 The server should populate the ANTIREPLAYCNT protocol element of the first response of an SDT sequence with the value zero (0), and set PRESARC accordingly. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01007 | SDT_REQ 13 If either PREQARC or PRESARC reaches the maximum value 65535 (0xFFFF), the client shall re-authenticate if it wishes to send more messages.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Secure communication and freshness protection; Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-006 | Medium Proposal Ready Open point: OP-005 | DetailsFull requirement text SDT_REQ 13 If either PREQARC or PRESARC reaches the maximum value 65535 (0xFFFF), the client shall re-authenticate if it wishes to send more messages. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 8 · page 8 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01008 | SDT_REQ 14 The client shall maintain the state variable PREQTAG.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Secure communication and freshness protection Architecture: System Core SSR: SSR-SYS-006 | Medium Proposal Ready Open point: - | DetailsFull requirement text SDT_REQ 14 The client shall maintain the state variable PREQTAG. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Secure communication and freshness protection | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01009 | SDT_REQ 15 The CipherScheme used when constructing an SDT message shall be indicated by the SIGENCRYPT protocol element according to Table 2.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces; Secure communication and freshness protection / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text SDT_REQ 15 The CipherScheme used when constructing an SDT message shall be indicated by the SIGENCRYPT protocol element according to Table 2. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces; Secure communication and freshness protection | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 9 · page 9 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01010 | SDT_REQ 16 The CipherSchemes SDT_AEAD_CHACHA20_POLY1305 and SDT_POLY1305 shall be supported.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Secure communication and freshness protection Architecture: System Core SSR: SSR-SYS-006 | Medium Proposal Ready Open point: - | DetailsFull requirement text SDT_REQ 16 The CipherSchemes SDT_AEAD_CHACHA20_POLY1305 and SDT_POLY1305 shall be supported. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Secure communication and freshness protection | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01011 | SDT_REQ 17 At SDT message reception, the recipient shall verify/decrypt the message using the CipherScheme indicated by the SIGENCRYPT protocol element.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces; Secure communication and freshness protection / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text SDT_REQ 17 At SDT message reception, the recipient shall verify/decrypt the message using the CipherScheme indicated by the SIGENCRYPT protocol element. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces; Secure communication and freshness protection | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01012 | SDT_REQ 18 In case of a positive SDT response, the server shall respond to a client request with the same CipherScheme used in the request.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Secure communication and freshness protection; Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-006 | Medium Proposal Ready Open point: OP-005 | DetailsFull requirement text SDT_REQ 18 In case of a positive SDT response, the server shall respond to a client request with the same CipherScheme used in the request. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01013 | SDT_REQ 19 The client may alter the CipherScheme between SDT requests within the same SDT sequence.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: Secure communication and freshness protection Architecture: None SSR: None | Low Proposal Ready Open point: - | DetailsFull requirement text SDT_REQ 19 The client may alter the CipherScheme between SDT requests within the same SDT sequence. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Secure communication and freshness protection | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-01014 | SDT_REQ 20 Client and server should keep state variables that indicate which CipherScheme, and resulting key, was used in the previous SDT transaction.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Key management | Feature / interface: Secure communication and freshness protection; Key management Architecture: Security Services SSR: SSR-KEY-006 | High Proposal Ready Open point: OP-005 | DetailsFull requirement text SDT_REQ 20 Client and server should keep state variables that indicate which CipherScheme, and resulting key, was used in the previous SDT transaction. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Key management | Security capability: Key management | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-KEY-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01015 | SDT_REQ 21 At construction of an SDT request, if SIGENCRYPT is different from PSIGENCRYPT, the client should re-run the KDF, and if and only if the authentication/encryption succeeds, update the state variables PSIGENCRYPT and PKEY with the new values.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Secure communication and freshness protection Architecture: System Core SSR: SSR-SYS-006 | High Proposal Ready Open point: - | DetailsFull requirement text SDT_REQ 21 At construction of an SDT request, if SIGENCRYPT is different from PSIGENCRYPT, the client should re-run the KDF, and if and only if the authentication/encryption succeeds, update the state variables PSIGENCRYPT and PKEY with the new values. Engineering expectation Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Secure communication and freshness protection | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01016 | SDT_REQ 22 At reception of an SDT request, if SIGENCRYPT is different from PSIGENCRYPT, the server should re-run the KDF, and if and only if the verification/decryption succeeds, update the state variables PSIGENCRYPT and PKEY with the new values.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Secure communication and freshness protection; Backend and IT integration; Security evidence and traceability / OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface SSR: SSR-VV-004 | High Proposal Ready Open point: OP-005 | DetailsFull requirement text SDT_REQ 22 At reception of an SDT request, if SIGENCRYPT is different from PSIGENCRYPT, the server should re-run the KDF, and if and only if the verification/decryption succeeds, update the state variables PSIGENCRYPT and PKEY with the new values. Engineering expectation Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Backend and IT integration; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Backend and IT Systems; OEM/Customer Review Interface | Work product: Requirement traceability record | SSR: SSR-VV-004 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 10 · page 10 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01017 | Client Server PREQARC = X PREQTAG=TAG_X PSIGENCRYPT=3 PKEY=p..p Check: ANTIREPLAYCNT > PREQARC SIGENCRYPT != PSIGENCRYPT: KDF(..) -> r..r decrypt(data, TAG_X+1)->ok Check: ANTIREPLAYCNT > PRESARC decrypt(data||PREQTAG, TAG_Y+1)->ok PRESARC = Y+1 PRESARC = Y+1 PREQARC = X PSIGENCRYPT=3 PKEY=p..p encrypt(data)->TAG_X+1 encrypt(data||TAG_X+1)->TAG_Y+1 S1 S2 S3 C1 C2 C3 SIGENCRYPT != PSIGENCRYPT: KDF(..) -> r..r Figure 4 – Change of CipherScheme mid sequence 3.2.1 HKDF Key Derivation SDT_REQ 23 Client and server shall support the HKDF [2] key derivation function using HMAC-SHA512 [3].Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Key management | Feature / interface: Secure communication and freshness protection; Key management Architecture: Security Services SSR: SSR-KEY-006 | High Proposal Ready Open point: OP-005 | DetailsFull requirement text Client Server PREQARC = X PREQTAG=TAG_X PSIGENCRYPT=3 PKEY=p..p Check: ANTIREPLAYCNT > PREQARC SIGENCRYPT != PSIGENCRYPT: KDF(..) -> r..r decrypt(data, TAG_X+1)->ok Check: ANTIREPLAYCNT > PRESARC decrypt(data||PREQTAG, TAG_Y+1)->ok PRESARC = Y+1 PRESARC = Y+1 PREQARC = X PSIGENCRYPT=3 PKEY=p..p encrypt(data)->TAG_X+1 encrypt(data||TAG_X+1)->TAG_Y+1 S1 S2 S3 C1 C2 C3 SIGENCRYPT != PSIGENCRYPT: KDF(..) -> r..r Figure 4 – Change of CipherScheme mid sequence 3.2.1 HKDF Key Derivation SDT_REQ 23 Client and server shall support the HKDF [2] key derivation function using HMAC-SHA512 [3]. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Key management | Security capability: Key management | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-KEY-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01018 | 𝐻𝐾𝐷𝐹(𝑖𝑘𝑚, 𝑠𝑎𝑙𝑡, 𝑖𝑛𝑓𝑜, 𝐿) → 𝑜𝑘𝑚 SDT_REQ 24 ikm : The ikm argument to the HKDF function shall be the octet string containing the SecuredDataTransmissionKey from the service 0x29 authentication state.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Accept with Assumption | Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior; Secure communication and freshness protection Architecture: Application Software SSR: SSR-RBAC-004 | High Proposal Ready Open point: - | DetailsFull requirement text 𝐻𝐾𝐷𝐹(𝑖𝑘𝑚, 𝑠𝑎𝑙𝑡, 𝑖𝑛𝑓𝑜, 𝐿) → 𝑜𝑘𝑚 SDT_REQ 24 ikm : The ikm argument to the HKDF function shall be the octet string containing the SecuredDataTransmissionKey from the service 0x29 authentication state. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Secure communication and freshness protection | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-RBAC-004 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01019 | SDT_REQ 25 salt: The salt argument to the HKDF function shall be set as the zero length octet string (null).Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior; Secure communication and freshness protection Architecture: Application Software SSR: SSR-SYS-008 | Medium Proposal Ready Open point: - | DetailsFull requirement text SDT_REQ 25 salt: The salt argument to the HKDF function shall be set as the zero length octet string (null). Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Secure communication and freshness protection | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-008 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01020 | SDT_REQ 26 info: The info argument to the HKDF function shall be set as the concatenation of the “SDT_0x84_KEY” octet string and the CipherScheme identifier.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior; Secure communication and freshness protection Architecture: Application Software SSR: SSR-SYS-008 | High Proposal Ready Open point: - | DetailsFull requirement text SDT_REQ 26 info: The info argument to the HKDF function shall be set as the concatenation of the “SDT_0x84_KEY” octet string and the CipherScheme identifier. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Secure communication and freshness protection | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-008 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 11 · page 11 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01021 | SDT_REQ 27 The L argument to the HKDF function shall be set to 64.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior; Secure communication and freshness protection Architecture: Application Software SSR: SSR-SYS-008 | Medium Proposal Ready Open point: - | DetailsFull requirement text SDT_REQ 27 The L argument to the HKDF function shall be set to 64. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Secure communication and freshness protection | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-008 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01022 | SDT_REQ 28 Octets 0-31 of the okm shall be used as key by the client to encrypt, and the server to decrypt, the request.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Key management | Feature / interface: Secure communication and freshness protection; Key management Architecture: Security Services SSR: SSR-KEY-006 | High Proposal Ready Open point: OP-005 | DetailsFull requirement text SDT_REQ 28 Octets 0-31 of the okm shall be used as key by the client to encrypt, and the server to decrypt, the request. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Key management | Security capability: Key management | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-KEY-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01023 | SDT_REQ 29 Octets 32-63 of the okm shall be used as key by the server to encrypt, and the client to decrypt, the response.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Key management | Feature / interface: Secure communication and freshness protection; Key management Architecture: Security Services SSR: SSR-KEY-006 | High Proposal Ready Open point: OP-005 | DetailsFull requirement text SDT_REQ 29 Octets 32-63 of the okm shall be used as key by the server to encrypt, and the client to decrypt, the response. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Key management | Security capability: Key management | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-KEY-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01024 | Figure 5 – Use of HKDF output key material (okm) with SDT_CHACHA20_POLY1305 In subsequent sections (3.2.2.1 and 3.2.2.2) the following requirements shall be met: SDT_REQ 30 𝐾: The 𝐾 argument shall be the key octet string of 32 octets.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | Key management | Feature / interface: Secure communication and freshness protection; Key management Architecture: Security Services SSR: SSR-KEY-006 | High Proposal Ready Open point: - | DetailsFull requirement text Figure 5 – Use of HKDF output key material (okm) with SDT_CHACHA20_POLY1305 In subsequent sections (3.2.2.1 and 3.2.2.2) the following requirements shall be met: SDT_REQ 30 𝐾: The 𝐾 argument shall be the key octet string of 32 octets. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Secure communication and freshness protection; Key management | Security capability: Key management | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-KEY-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01025 | SDT_REQ 31 𝑁: The 𝑁 shall be an octet string of length 12, constructed as follows:the first 10 octets shall be set to 6E6F6E73656E73652121, and - the remaining 2 octets shall be ANTIREPLAYCNT.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Secure communication and freshness protection Architecture: System Core SSR: SSR-SYS-006 | Medium Proposal Ready Open point: - | DetailsFull requirement text SDT_REQ 31 𝑁: The 𝑁 shall be an octet string of length 12, constructed as follows: - the first 10 octets shall be set to 6E6F6E73656E73652121, and - the remaining 2 octets shall be ANTIREPLAYCNT. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Secure communication and freshness protection | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01026 | SDT_REQ 32 𝑃: The 𝑃 (Plaintext) argument shall be the octet string that is the concatenation of the INTMSGREQID and SRVSPECPARAM.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Secure communication and freshness protection Architecture: System Core SSR: SSR-SYS-006 | Medium Proposal Ready Open point: - | DetailsFull requirement text SDT_REQ 32 𝑃: The 𝑃 (Plaintext) argument shall be the octet string that is the concatenation of the INTMSGREQID and SRVSPECPARAM. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Secure communication and freshness protection | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01027 | SDT_REQ 33 𝐶: When injected into, or extracted from an SDT message, the first octet of 𝐶 shall correspond to INTMSGREQID, and the remaining octets to SRVSPECPARAM.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces; Secure communication and freshness protection / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text SDT_REQ 33 𝐶: When injected into, or extracted from an SDT message, the first octet of 𝐶 shall correspond to INTMSGREQID, and the remaining octets to SRVSPECPARAM. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces; Secure communication and freshness protection | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 12 · page 12 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01028 | Internal Page 13 (29) 3.2.2.1 Client Encryption/Decryption 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑒𝑛𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴, 𝑃) → 𝐶, 𝑇𝐴𝐺 SDT_REQ 34 The client shall encrypt and authenticate the SDT request with the 𝐴 argument set to the concatenated octet string comprised of the SDT, APAR, SIGENCRYPT, SIGLEN and ANTIREPLAYCNT protocol elements.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | Authentication | Feature / interface: Secure communication and freshness protection; Authentication Architecture: Security Services SSR: SSR-DAI-005 | High Proposal Ready Open point: - | DetailsFull requirement text Internal Page 13 (29) 3.2.2.1 Client Encryption/Decryption 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑒𝑛𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴, 𝑃) → 𝐶, 𝑇𝐴𝐺 SDT_REQ 34 The client shall encrypt and authenticate the SDT request with the 𝐴 argument set to the concatenated octet string comprised of the SDT, APAR, SIGENCRYPT, SIGLEN and ANTIREPLAYCNT protocol elements. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Secure communication and freshness protection; Authentication | Security capability: Authentication | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-DAI-005 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 13 · page 13 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01029 | SDT_REQ 35 The client shall populate the APAR protocol element in the request so that bits 0, 4, 5 and 6 are set to true.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces; Secure communication and freshness protection / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text SDT_REQ 35 The client shall populate the APAR protocol element in the request so that bits 0, 4, 5 and 6 are set to true. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces; Secure communication and freshness protection | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 13 · page 13 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01030 | SDT_REQ 36 The client shall populate the SIGLEN protocol element in the request with 16 (0x0010).Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces; Secure communication and freshness protection / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text SDT_REQ 36 The client shall populate the SIGLEN protocol element in the request with 16 (0x0010). Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces; Secure communication and freshness protection | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 13 · page 13 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01031 | SDT_REQ 37 The client shall populate the SIGMACBYTE protocol element in the request with 𝑇𝐴𝐺.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces; Secure communication and freshness protection / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text SDT_REQ 37 The client shall populate the SIGMACBYTE protocol element in the request with 𝑇𝐴𝐺. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces; Secure communication and freshness protection | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 13 · page 13 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01032 | SDT_REQ 38 The client shall store 𝑇𝐴𝐺 in its state variable PREQTAG.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Secure communication and freshness protection Architecture: System Core SSR: SSR-SYS-006 | Medium Proposal Ready Open point: - | DetailsFull requirement text SDT_REQ 38 The client shall store 𝑇𝐴𝐺 in its state variable PREQTAG. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Secure communication and freshness protection | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 13 · page 13 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01033 | 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑑𝑒𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴, 𝐶, 𝑇𝐴𝐺) → 𝑜𝑘/𝑛𝑜𝑘, 𝑃 The client shall decrypt and verify the SDT response with: SDT_REQ 39 the 𝐴 argument set to the concatenated octet string comprised of the SDTPR, APAR, SIGENCRYPT, SIGLEN, ANTIREPLAYCNT protocol elements of the response and the value stored in the state variable PREQTAG.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces; Secure communication and freshness protection / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑑𝑒𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴, 𝐶, 𝑇𝐴𝐺) → 𝑜𝑘/𝑛𝑜𝑘, 𝑃 The client shall decrypt and verify the SDT response with: SDT_REQ 39 the 𝐴 argument set to the concatenated octet string comprised of the SDTPR, APAR, SIGENCRYPT, SIGLEN, ANTIREPLAYCNT protocol elements of the response and the value stored in the state variable PREQTAG. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces; Secure communication and freshness protection | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 13 · page 13 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01034 | 3.2.2.2 Server Decryption/Encryption 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑑𝑒𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴, 𝐶, 𝑇𝐴𝐺) → 𝑜𝑘/𝑛𝑜𝑘, 𝑃 SDT_REQ 42 The server shall decrypt and verify the SDT request with the 𝐴 argument set to the concatenated octet string comprised of the SDT, APAR, SIGENCRYPT, SIGLEN and ANTIREPLAYCNT protocol elements.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Secure communication and freshness protection; Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-006 | Medium Proposal Ready Open point: OP-005 | DetailsFull requirement text 3.2.2.2 Server Decryption/Encryption 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑑𝑒𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴, 𝐶, 𝑇𝐴𝐺) → 𝑜𝑘/𝑛𝑜𝑘, 𝑃 SDT_REQ 42 The server shall decrypt and verify the SDT request with the 𝐴 argument set to the concatenated octet string comprised of the SDT, APAR, SIGENCRYPT, SIGLEN and ANTIREPLAYCNT protocol elements. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 13 · page 13 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01035 | 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑒𝑛𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴, 𝑃) → 𝐶, 𝑇𝐴𝐺 The server shall encrypt and authenticate the SDT response with: SDT_REQ 44 the 𝐴 argument set to the concatenated octet string comprised of the SDTPR, APAR, SIGENCRYPT, SIGLEN and ANTIREPLAYCNT protocol elements of the response and the octet string carried by the SIGMACBYTE protocol element of the corresponding request.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Authentication | Feature / interface: Secure communication and freshness protection; Authentication Architecture: Security Services SSR: SSR-DAI-005 | High Proposal Ready Open point: OP-005 | DetailsFull requirement text 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑒𝑛𝑐𝑟𝑦𝑝𝑡(𝐾, 𝑁, 𝐴, 𝑃) → 𝐶, 𝑇𝐴𝐺 The server shall encrypt and authenticate the SDT response with: SDT_REQ 44 the 𝐴 argument set to the concatenated octet string comprised of the SDTPR, APAR, SIGENCRYPT, SIGLEN and ANTIREPLAYCNT protocol elements of the response and the octet string carried by the SIGMACBYTE protocol element of the corresponding request. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Authentication | Security capability: Authentication | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-DAI-005 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 13 · page 13 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01036 | SDT_REQ 46 The server shall populate the APAR protocol element in the response so that bits 4 and 5 are set to true.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Secure communication and freshness protection; Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-006 | Medium Proposal Ready Open point: OP-005 | DetailsFull requirement text SDT_REQ 46 The server shall populate the APAR protocol element in the response so that bits 4 and 5 are set to true. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 13 · page 13 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01037 | Internal Page 14 (29) SDT_REQ 47 The server shall populate the SIGLEN protocol element in the request with 16 (0x0010).Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Secure communication and freshness protection; Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-006 | Medium Proposal Ready Open point: OP-005 | DetailsFull requirement text Internal Page 14 (29) SDT_REQ 47 The server shall populate the SIGLEN protocol element in the request with 16 (0x0010). Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 14 · page 14 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01038 | SDT_REQ 48 The server shall populate the SIGMACBYTE protocol element in the request with 𝑇𝐴𝐺.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Secure communication and freshness protection; Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-006 | Medium Proposal Ready Open point: OP-005 | DetailsFull requirement text SDT_REQ 48 The server shall populate the SIGMACBYTE protocol element in the request with 𝑇𝐴𝐺. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 14 · page 14 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01039 | one octet, and the rest should go in the SRVSPECPARAM protocol element.Expectation: Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. | Accept with Assumption | Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Low Proposal Ready Open point: - | DetailsFull requirement text one octet, and the rest should go in the SRVSPECPARAM protocol element. Engineering expectation Engineering work is expected to allocate this requirement to the affected ECU function, interface, architecture element, or evidence work product. Supplier proposal Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 14 · page 14 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01040 | SDT_REQ 49 The L argument to the HKDF function shall be set to 64.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: Application software behavior; Secure communication and freshness protection Architecture: Application Software SSR: SSR-SYS-008 | Medium Proposal Ready Open point: - | DetailsFull requirement text SDT_REQ 49 The L argument to the HKDF function shall be set to 64. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Application software behavior; Secure communication and freshness protection | Security capability: None | Interface: None | Architecture: Application Software | Work product: System/architecture design | SSR: SSR-SYS-008 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 15 · page 15 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01041 | SDT_REQ 50 Octets 0-31 of the okm shall be used as key by the client to authenticate, and the server to verify, the request.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Authentication | Feature / interface: Secure communication and freshness protection; Authentication Architecture: Security Services SSR: SSR-DAI-005 | High Proposal Ready Open point: OP-005 | DetailsFull requirement text SDT_REQ 50 Octets 0-31 of the okm shall be used as key by the client to authenticate, and the server to verify, the request. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Authentication | Security capability: Authentication | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-DAI-005 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 15 · page 15 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01042 | SDT_REQ 51 Octets 32-63 of the okm shall be used as key by the server to authenticate, and the client to verify, the response.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Authentication | Feature / interface: Secure communication and freshness protection; Authentication Architecture: Security Services SSR: SSR-DAI-005 | High Proposal Ready Open point: OP-005 | DetailsFull requirement text SDT_REQ 51 Octets 32-63 of the okm shall be used as key by the server to authenticate, and the client to verify, the response. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Authentication | Security capability: Authentication | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-DAI-005 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 15 · page 15 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01043 | Figure 7 – Use of HKDF output key material (okm) with SDT_POLY1305 In subsequent sections (3.2.3.1 and 3.2.3.2), the following requirements shall be met: SDT_REQ 52 𝐾: The 𝐾 argument shall be the key octet string of 32 octets.Expectation: Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | Key management | Feature / interface: Secure communication and freshness protection; Key management Architecture: Security Services SSR: SSR-KEY-006 | High Proposal Ready Open point: - | DetailsFull requirement text Figure 7 – Use of HKDF output key material (okm) with SDT_POLY1305 In subsequent sections (3.2.3.1 and 3.2.3.2), the following requirements shall be met: SDT_REQ 52 𝐾: The 𝐾 argument shall be the key octet string of 32 octets. Engineering expectation Trust material is expected to be provisioned, stored, validated, renewed, and revoked through an agreed key and certificate lifecycle. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Secure communication and freshness protection; Key management | Security capability: Key management | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-KEY-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 15 · page 15 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling High, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01044 | SDT_REQ 91 𝑁: The 𝑁 shall be an octet string of length 12, constructed as follows:the first 10 octets shall be set to 6E6F6E73656E73652121, and - the remaining 2 octets shall be ANTIREPLAYCNT.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Secure communication and freshness protection Architecture: System Core SSR: SSR-SYS-006 | Medium Proposal Ready Open point: - | DetailsFull requirement text SDT_REQ 91 𝑁: The 𝑁 shall be an octet string of length 12, constructed as follows: - the first 10 octets shall be set to 6E6F6E73656E73652121, and - the remaining 2 octets shall be ANTIREPLAYCNT. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Secure communication and freshness protection | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 15 · page 15 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01045 | Internal Page 16 (29) 3.2.3.1 Client Authentication/Verification 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑎𝑢𝑡ℎ𝑒𝑛𝑡𝑖𝑐𝑎𝑡𝑒(𝐾, 𝑁, 𝐴, 𝑃𝑛𝑢𝑙𝑙) → 𝐶𝑛𝑢𝑙𝑙, 𝑇𝐴𝐺 SDT_REQ 54 The client shall authenticate the SDT request with the 𝐴 argument set to the octet string comprised of all protocol elements of the SDT request, excluding the SIGMACBYTE protocol element.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces; Secure communication and freshness protection; Security evidence and traceability / External Interfaces; OEM/Customer Review Interface Architecture: External Interfaces; OEM/Customer Review Interface SSR: SSR-VV-005 | High Proposal Ready Open point: - | DetailsFull requirement text Internal Page 16 (29) 3.2.3.1 Client Authentication/Verification 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑎𝑢𝑡ℎ𝑒𝑛𝑡𝑖𝑐𝑎𝑡𝑒(𝐾, 𝑁, 𝐴, 𝑃𝑛𝑢𝑙𝑙) → 𝐶𝑛𝑢𝑙𝑙, 𝑇𝐴𝐺 SDT_REQ 54 The client shall authenticate the SDT request with the 𝐴 argument set to the octet string comprised of all protocol elements of the SDT request, excluding the SIGMACBYTE protocol element. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces; Secure communication and freshness protection; Security evidence and traceability | Security capability: None | Interface: External Interfaces; OEM/Customer Review Interface | Architecture: External Interfaces; OEM/Customer Review Interface | Work product: System/architecture design | SSR: SSR-VV-005 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 16 · page 16 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01046 | SDT_REQ 55 The client shall populate the APAR protocol element in the request so that bits 0, 5 and 6 are set to true.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces; Secure communication and freshness protection / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text SDT_REQ 55 The client shall populate the APAR protocol element in the request so that bits 0, 5 and 6 are set to true. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces; Secure communication and freshness protection | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 16 · page 16 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01047 | SDT_REQ 56 The client shall populate the SIGLEN protocol element in the request with 16 (0x0010).Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces; Secure communication and freshness protection / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text SDT_REQ 56 The client shall populate the SIGLEN protocol element in the request with 16 (0x0010). Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces; Secure communication and freshness protection | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 16 · page 16 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01048 | SDT_REQ 57 The client shall populate the SIGMACBYTE protocol element in the request with 𝑇𝐴𝐺.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces; Secure communication and freshness protection / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text SDT_REQ 57 The client shall populate the SIGMACBYTE protocol element in the request with 𝑇𝐴𝐺. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces; Secure communication and freshness protection | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 16 · page 16 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01049 | SDT_REQ 58 The client shall store 𝑇𝐴𝐺 in its state variable PREQTAG.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Secure communication and freshness protection Architecture: System Core SSR: SSR-SYS-006 | Medium Proposal Ready Open point: - | DetailsFull requirement text SDT_REQ 58 The client shall store 𝑇𝐴𝐺 in its state variable PREQTAG. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Secure communication and freshness protection | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 16 · page 16 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01050 | 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑣𝑒𝑟𝑖𝑓𝑦(𝐾, 𝑁, 𝐴, 𝐶𝑛𝑢𝑙𝑙, 𝑇𝐴𝐺) → ok/nok,𝑃𝑛𝑢𝑙𝑙 SDT_REQ 59 The client shall verify the SDT response with the 𝐴 argument set to the octet string comprised of all protocol elements of the SDT response, excluding the SIGMACBYTE protocol element, concatenated with the octet string stored in the state variable PREQTAG.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces; Secure communication and freshness protection / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑣𝑒𝑟𝑖𝑓𝑦(𝐾, 𝑁, 𝐴, 𝐶𝑛𝑢𝑙𝑙, 𝑇𝐴𝐺) → ok/nok,𝑃𝑛𝑢𝑙𝑙 SDT_REQ 59 The client shall verify the SDT response with the 𝐴 argument set to the octet string comprised of all protocol elements of the SDT response, excluding the SIGMACBYTE protocol element, concatenated with the octet string stored in the state variable PREQTAG. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces; Secure communication and freshness protection | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 16 · page 16 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01051 | 3.2.3.2 Server Verification/Authentication 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑣𝑒𝑟𝑖𝑓𝑦(𝐾, 𝑁, 𝐴, 𝐶𝑛𝑢𝑙𝑙, 𝑇𝐴𝐺) → ok/nok,𝑃𝑛𝑢𝑙𝑙 SDT_REQ 61 The server shall verify the SDT request with the 𝐴 argument set to the octet string comprised of all protocol elements of the SDT response, excluding the SIGMACBYTE protocol element.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Secure communication and freshness protection; Backend and IT integration; Security evidence and traceability / OEM/Customer Review Interface Architecture: Backend and IT Systems; OEM/Customer Review Interface SSR: SSR-VV-004 | High Proposal Ready Open point: OP-005 | DetailsFull requirement text 3.2.3.2 Server Verification/Authentication 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑣𝑒𝑟𝑖𝑓𝑦(𝐾, 𝑁, 𝐴, 𝐶𝑛𝑢𝑙𝑙, 𝑇𝐴𝐺) → ok/nok,𝑃𝑛𝑢𝑙𝑙 SDT_REQ 61 The server shall verify the SDT request with the 𝐴 argument set to the octet string comprised of all protocol elements of the SDT response, excluding the SIGMACBYTE protocol element. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Backend and IT integration; Security evidence and traceability | Security capability: None | Interface: OEM/Customer Review Interface | Architecture: Backend and IT Systems; OEM/Customer Review Interface | Work product: Requirement traceability record | SSR: SSR-VV-004 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 16 · page 16 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01052 | 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑎𝑢𝑡ℎ𝑒𝑛𝑡𝑖𝑐𝑎𝑡𝑒(𝐾, 𝑁, 𝐴, 𝑃𝑛𝑢𝑙𝑙) → 𝐶𝑛𝑢𝑙𝑙, 𝑇𝐴𝐺 SDT_REQ 63 The server shall authenticate the SDT response with the 𝐴 argument set to the octet string comprised of all protocol elements of the SDT response, excluding the SIGMACBYTE protocol element, concatenated with the octet string carried by the SIGMACBYTE protocol element of the corresponding request.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Secure communication and freshness protection; Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-006 | Medium Proposal Ready Open point: OP-005 | DetailsFull requirement text 𝐶𝐻𝐴𝐶𝐻𝐴20-POLY1305𝑎𝑢𝑡ℎ𝑒𝑛𝑡𝑖𝑐𝑎𝑡𝑒(𝐾, 𝑁, 𝐴, 𝑃𝑛𝑢𝑙𝑙) → 𝐶𝑛𝑢𝑙𝑙, 𝑇𝐴𝐺 SDT_REQ 63 The server shall authenticate the SDT response with the 𝐴 argument set to the octet string comprised of all protocol elements of the SDT response, excluding the SIGMACBYTE protocol element, concatenated with the octet string carried by the SIGMACBYTE protocol element of the corresponding request. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 16 · page 16 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01053 | Internal Page 17 (29) SDT_REQ 64 The server shall populate the APAR protocol element in the response so that bit 5 is set to true.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Secure communication and freshness protection; Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-006 | Medium Proposal Ready Open point: OP-005 | DetailsFull requirement text Internal Page 17 (29) SDT_REQ 64 The server shall populate the APAR protocol element in the response so that bit 5 is set to true. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 17 · page 17 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01054 | SDT_REQ 65 The server shall populate the SIGLEN protocol element in the response with 16 (0x0010).Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Secure communication and freshness protection; Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-006 | Medium Proposal Ready Open point: OP-005 | DetailsFull requirement text SDT_REQ 65 The server shall populate the SIGLEN protocol element in the response with 16 (0x0010). Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 17 · page 17 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01055 | SDT_REQ 66 The client shall populate the SIGMACBYTE protocol element in the response with 𝑇𝐴𝐺.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: External interfaces; Secure communication and freshness protection / External Interfaces Architecture: External Interfaces SSR: SSR-COM-002 | Medium Proposal Ready Open point: - | DetailsFull requirement text SDT_REQ 66 The client shall populate the SIGMACBYTE protocol element in the response with 𝑇𝐴𝐺. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: External interfaces; Secure communication and freshness protection | Security capability: None | Interface: External Interfaces | Architecture: External Interfaces | Work product: System/architecture design | SSR: SSR-COM-002 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 17 · page 17 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01056 | The SDT positive response may of course contain an encapsulated negative UDS response.Expectation: Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. | Informational Only | Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability.Decision: No action unless the customer confirms it is binding. | None | Feature / interface: Secure communication and freshness protection Architecture: None SSR: None | Low Proposal Ready Open point: - | DetailsFull requirement text The SDT positive response may of course contain an encapsulated negative UDS response. Engineering expectation Diagnostic access is expected to be authenticated, role-authorized, logged, and finalized through customer-confirmed service allocation. Supplier proposal Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. Rationale Source classifies this as Functional (non-binding). Implementation approach Capture as background context in the concept; no work product committed. Acceptance condition Customer confirms it is binding. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Secure communication and freshness protection | Security capability: None | Interface: None | Architecture: None | Work product: System/architecture design | SSR: None Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 18 · page 18 Estimation / resource / tool / IT / hardware impact Effort Low, Competence Low, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action No action unless the customer confirms it is binding. |
| REQ-AUTO-01057 | SDT_REQ 67 Other than the NRCs 0x3A, 0x13 and 0x21, specified by ISO14229-1:2020 [1], the server shall support the NRC 0x34 “authenticationRequired”.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Secure communication and freshness protection; Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-006 | High Proposal Ready Open point: OP-005 | DetailsFull requirement text SDT_REQ 67 Other than the NRCs 0x3A, 0x13 and 0x21, specified by ISO14229-1:2020 [1], the server shall support the NRC 0x34 “authenticationRequired”. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 18 · page 18 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01058 | Internal Page 19 (29) Figure 10 – Server's error and state handling SDT_REQ 68 At reception of an SDT request, if the security sub-layer is busy, the server shall respond with an SDT negative response using the NRC 0x21.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Secure communication | Feature / interface: Secure communication and freshness protection; Cybersecurity requirement handling Architecture: Security Services SSR: SSR-COM-008 | High Proposal Ready Open point: OP-005 | DetailsFull requirement text Internal Page 19 (29) Figure 10 – Server's error and state handling SDT_REQ 68 At reception of an SDT request, if the security sub-layer is busy, the server shall respond with an SDT negative response using the NRC 0x21. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Cybersecurity requirement handling | Security capability: Secure communication | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-COM-008 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 19 · page 19 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01059 | SDT_REQ 69 At reception of an SDT request, if the requesting client is unauthenticated, the server shall respond with an SDT negative response using the NRC 0x34.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Secure communication and freshness protection; Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-006 | Medium Proposal Ready Open point: OP-005 | DetailsFull requirement text SDT_REQ 69 At reception of an SDT request, if the requesting client is unauthenticated, the server shall respond with an SDT negative response using the NRC 0x34. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 19 · page 19 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01060 | Internal Page 20 (29) SDT_REQ 70 At reception of an SDT request, if the request is too short or otherwise malformed, the server shall respond with an SDT negative response using the NRC 0x13.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Secure communication and freshness protection; Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-006 | Medium Proposal Ready Open point: OP-005 | DetailsFull requirement text Internal Page 20 (29) SDT_REQ 70 At reception of an SDT request, if the request is too short or otherwise malformed, the server shall respond with an SDT negative response using the NRC 0x13. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 20 · page 20 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01061 | SDT_REQ 71 At reception of an SDT request, if ANTIREPLAYCNT ≤ PREQARC, the server shall respond with an SDT negative response using the NRC 0x3A.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Secure communication and freshness protection; Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-006 | Medium Proposal Ready Open point: OP-005 | DetailsFull requirement text SDT_REQ 71 At reception of an SDT request, if ANTIREPLAYCNT ≤ PREQARC, the server shall respond with an SDT negative response using the NRC 0x3A. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 20 · page 20 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01062 | SDT_REQ 88 At reception of an SDT request, if PRESARC is exhausted, the server shall respond with an SDT negative response using the NRC 0x3A.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Secure communication and freshness protection; Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-006 | Medium Proposal Ready Open point: OP-005 | DetailsFull requirement text SDT_REQ 88 At reception of an SDT request, if PRESARC is exhausted, the server shall respond with an SDT negative response using the NRC 0x3A. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 20 · page 20 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01063 | SDT_REQ 72 At reception of an SDT request, if SIGENCRYPT is not supported, the server shall respond with an SDT negative response using the NRC 0x3A.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Secure communication and freshness protection; Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-006 | Medium Proposal Ready Open point: OP-005 | DetailsFull requirement text SDT_REQ 72 At reception of an SDT request, if SIGENCRYPT is not supported, the server shall respond with an SDT negative response using the NRC 0x3A. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 20 · page 20 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01064 | SDT_REQ 73 At reception of an SDT request, if APAR is in conflict with SIGENCRYPT, the server shall respond with an SDT negative response using the NRC 0x3A.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Secure communication and freshness protection; Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-006 | Medium Proposal Ready Open point: OP-005 | DetailsFull requirement text SDT_REQ 73 At reception of an SDT request, if APAR is in conflict with SIGENCRYPT, the server shall respond with an SDT negative response using the NRC 0x3A. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 20 · page 20 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01065 | SDT_REQ 74 At reception of an SDT request, if SIGLEN is in conflict with SIGENCRYPT, the server shall respond with an SDT negative response using the NRC 0x3A.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Secure communication and freshness protection; Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-006 | Medium Proposal Ready Open point: OP-005 | DetailsFull requirement text SDT_REQ 74 At reception of an SDT request, if SIGLEN is in conflict with SIGENCRYPT, the server shall respond with an SDT negative response using the NRC 0x3A. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 20 · page 20 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01066 | SDT_REQ 75 At reception of an SDT request, if the server fails to verify/decrypt the request, the server shall respond with an SDT negative response using the NRC 0x3A.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Secure communication and freshness protection; Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-006 | Medium Proposal Ready Open point: OP-005 | DetailsFull requirement text SDT_REQ 75 At reception of an SDT request, if the server fails to verify/decrypt the request, the server shall respond with an SDT negative response using the NRC 0x3A. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 20 · page 20 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01067 | SDT_REQ 76 The server shall update its state, (set PREQARC to the value received in the ANTIREPLAYCNT protocol element in the SDT request), if and only if it successfully verifies/decrypts the SDT request.Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Secure communication and freshness protection; Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-006 | High Proposal Ready Open point: OP-005 | DetailsFull requirement text SDT_REQ 76 The server shall update its state, (set PREQARC to the value received in the ANTIREPLAYCNT protocol element in the SDT request), if and only if it successfully verifies/decrypts the SDT request. Engineering expectation Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 20 · page 20 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01068 | SDT_REQ 77 The server shall update its state, (increment PRESARC by one (1)), if and only if it can successfully authenticate/encrypt the SDT response (“S3”).Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | Authentication | Feature / interface: Secure communication and freshness protection; Authentication Architecture: Security Services SSR: SSR-DAI-005 | High Proposal Ready Open point: OP-005 | DetailsFull requirement text SDT_REQ 77 The server shall update its state, (increment PRESARC by one (1)), if and only if it can successfully authenticate/encrypt the SDT response (“S3”). Engineering expectation Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Authentication | Security capability: Authentication | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-DAI-005 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 20 · page 20 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Low, IT High, HW/Test Medium Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01069 | SDT_REQ 78 The client shall update its state, (increment PREQARC by one (1), if and only if it can successfully authenticate/encrypt the SDT request (“C2”).Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | Authentication | Feature / interface: Secure communication and freshness protection; Authentication Architecture: Security Services SSR: SSR-DAI-005 | High Proposal Ready Open point: - | DetailsFull requirement text SDT_REQ 78 The client shall update its state, (increment PREQARC by one (1), if and only if it can successfully authenticate/encrypt the SDT request (“C2”). Engineering expectation Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: Secure communication and freshness protection; Authentication | Security capability: Authentication | Interface: None | Architecture: Security Services | Work product: Cybersecurity concept; Cybersecurity verification report | SSR: SSR-DAI-005 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 21 · page 21 Estimation / resource / tool / IT / hardware impact Effort High, Competence High, Tooling Low, IT Low, HW/Test Medium Risk if unresolved Unverified security control could leave a residual risk in the cybersecurity case. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01070 | Internal Page 22 (29) Figure 12 – The client's error and state handling SDT_REQ 79 At reception of an SDT response, if the client is unauthenticated, the client shall discard the SDT_REQ 80 At reception of an SDT response, if the request is too short or otherwise malformed, the client shall discard the response.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Secure communication and freshness protection Architecture: System Core SSR: SSR-SYS-006 | Medium Proposal Ready Open point: - | DetailsFull requirement text Internal Page 22 (29) Figure 12 – The client's error and state handling SDT_REQ 79 At reception of an SDT response, if the client is unauthenticated, the client shall discard the SDT_REQ 80 At reception of an SDT response, if the request is too short or otherwise malformed, the client shall discard the response. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Secure communication and freshness protection | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 22 · page 22 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01071 | SDT_REQ 81 At reception of an SDT response, if ANTIREPLAYCNT ≤ PRESARC, the client shall discard theExpectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Secure communication and freshness protection Architecture: System Core SSR: SSR-SYS-006 | Medium Proposal Ready Open point: - | DetailsFull requirement text SDT_REQ 81 At reception of an SDT response, if ANTIREPLAYCNT ≤ PRESARC, the client shall discard the Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Secure communication and freshness protection | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 22 · page 22 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01072 | Internal Page 23 (29) SDT_REQ 82 At reception of an SDT response, if SIGENCRYPT is not supported, the client shall discard the SDT_REQ 83 At reception of an SDT response, if APAR is in conflict with SIGENCRYPT, the client shall discard the response.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Secure communication and freshness protection Architecture: System Core SSR: SSR-SYS-006 | Medium Proposal Ready Open point: - | DetailsFull requirement text Internal Page 23 (29) SDT_REQ 82 At reception of an SDT response, if SIGENCRYPT is not supported, the client shall discard the SDT_REQ 83 At reception of an SDT response, if APAR is in conflict with SIGENCRYPT, the client shall discard the response. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Secure communication and freshness protection | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 23 · page 23 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01073 | SDT_REQ 84 At reception of an SDT response, if SIGLEN is in conflict with SIGENCRYPT, the client shall discard the response.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Secure communication and freshness protection Architecture: System Core SSR: SSR-SYS-006 | Medium Proposal Ready Open point: - | DetailsFull requirement text SDT_REQ 84 At reception of an SDT response, if SIGLEN is in conflict with SIGENCRYPT, the client shall discard the response. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Secure communication and freshness protection | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 23 · page 23 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01074 | SDT_REQ 85 At reception of an SDT response, if the client fails to verify/decrypt the response, the client shall discard the response.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Accept with Assumption | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Validate assumption with customer; complete mapping; implement. | None | Feature / interface: System behavior; Secure communication and freshness protection Architecture: System Core SSR: SSR-SYS-006 | Medium Proposal Ready Open point: - | DetailsFull requirement text SDT_REQ 85 At reception of an SDT response, if the client fails to verify/decrypt the response, the client shall discard the response. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security-relevant requirement the ECU can own once responsibility/method is confirmed. Implementation approach Allocate to the relevant security capability and capture in the cybersecurity concept and verification plan. Acceptance condition Customer approves the proposed implementation method and responsibility allocation. Customer feedback - Customer decision - Customer clarification / open point - Traceability Feature: System behavior; Secure communication and freshness protection | Security capability: None | Interface: None | Architecture: System Core | Work product: System/architecture design | SSR: SSR-SYS-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 23 · page 23 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT Low, HW/Test Low Risk if unresolved Limited; standard implementation and verification risk. Next action Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-01075 | SDT_REQ 86 The client shall update its state, (set PRESARC to the value received in the ANTIREPLAYCNT protocol element in the SDT response), if and only if it successfully verifies/decrypts the SDT response (“C3”).Expectation: Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Secure communication and freshness protection; Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-006 | High Proposal Ready Open point: OP-005 | DetailsFull requirement text SDT_REQ 86 The client shall update its state, (set PRESARC to the value received in the ANTIREPLAYCNT protocol element in the SDT response), if and only if it successfully verifies/decrypts the SDT response (“C3”). Engineering expectation Software update handling is expected to preserve authenticity, integrity, and controlled boot/application state transitions. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 23 · page 23 Estimation / resource / tool / IT / hardware impact Effort High, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-01076 | SDT_REQ 87 If the client determines an SDT request to be lost in transit, or, if it receives an SDT negative response with NRC BRR (0x21), the client shall • repeat the request byte for byte and leave state variables unchanged.Expectation: ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. | Partially Accept | Partially accept. Supplier can support ECU-side SecOC/SDT processing, freshness checks, and failure handling; customer must confirm protected signals/PDUs, key distribution, and freshness profile.Decision: Agree responsibility split (DIA) for the non-ECU portion. | None | Feature / interface: Secure communication and freshness protection; Backend and IT integration Architecture: Backend and IT Systems SSR: SSR-COM-006 | Medium Proposal Ready Open point: OP-005 | DetailsFull requirement text SDT_REQ 87 If the client determines an SDT request to be lost in transit, or, if it receives an SDT negative response with NRC BRR (0x21), the client shall • repeat the request byte for byte and leave state variables unchanged. Engineering expectation ECU communication interfaces are expected to apply agreed boundary controls, authenticity/integrity checks, and freshness handling where allocated. Supplier proposal 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. Rationale Security requirement references OEM/backend/PKI/fleet-owned infrastructure. Implementation approach Implement and verify the ECU-allocated portion; allocate the backend/PKI/fleet portion to the OEM via the DIA. Acceptance condition Customer confirms the responsibility split (DIA/RASIC) for the non-ECU portion. Customer feedback - Customer decision - Customer clarification / open point OP-005 Traceability Feature: Secure communication and freshness protection; Backend and IT integration | Security capability: None | Interface: None | Architecture: Backend and IT Systems | Work product: Requirement traceability record | SSR: SSR-COM-006 Source PDF Source evidence converted/markdown-cleaned/CVS32.md · CVS32 > Page 23 · page 23 Estimation / resource / tool / IT / hardware impact Effort Medium, Competence Medium, Tooling Low, IT High, HW/Test Low Risk if unresolved Responsibility gap between OEM and supplier could leave a security control unimplemented or duplicated. Next action Agree responsibility split (DIA) for the non-ECU portion. |
Use the filters above to narrow the list. Each row expands to full evidence.
Open Point Summary
| Open Point ID | Topic | Priority | Related Requirements | Status |
|---|---|---|---|---|
| OP-001 | ECU designation, variant and item definition for TARA | High | 3 | Open |
| OP-002 | Diagnostic security role model and service authorization | High | 79 | Open |
| OP-003 | Key and certificate ownership, provisioning and lifecycle | High | 20 | Open |
| OP-004 | Secure software update / backend campaign responsibility | High | 20 | Open |
| OP-005 | Secure on-board communication (SecOC/SDT) signal allocation | High | 37 | Open |
| OP-009 | Cybersecurity work products, DIA and responsibility split | High | 1 | Open |
| OP-006 | Incident response and vulnerability management ownership | Medium | 1 | Open |
| OP-008 | Production, development and debug-interface hardening | Medium | 2 | Open |
| OP-011 | Document-specific scope and responsibility confirmation | Medium | 4 | Open |